Typing system vs. Java

[Ralf Muschall]

<brueckd at tbye.com> writes:

> I guess my thinking is something like this: _if_ the language forces the
> programmer to be very involved with details like type information, then
> some sort of strict, compile-time checking is a Good Thing. _If_, however,
> the programmer doesn't have to deal with those issues (or at least not to
> the same degree), then many of the related problems go away (or are
> present to a much smaller degree), and therefore the ability to check for
> those problems is much less beneficial. For example, Python handles most

This is only valid for very simple type systems.

In a really statically typed language, your example would go as follows
(I don't speak curl, probably my stuff is no valid curl syntax):

>    let v = new
#    for now, leave it to the language what type v is

>    let s = "hi"
#    the language sees that the type of s must be String

>    {v.append s}
#    from this line the language sees that the type of v must have been
#    Array of String, since anything else would not fit.

>    let i:int = v[0]        # ERROR: can't assign a String to an int
True - if you want to protect yourself against mistakes, add explicit
type information.  This is one of the purposes it is intended for - the
other one is to allow the compiler to decide all types at compile
time, thus avoiding boxed data, checks etc. at runtime.

Without the type info in the last line, the compiler would create an
i of type int.

Without giving any type hints, two things can happen in a statically
typed language:  (1) The compiler solves the constraints and finds all
types, (2) it can't since there are more solutions and give an error
message (or assumes a default).

E.g. in hugs you get 2/3 -> 0.6666666667 (there are no typecasts at
all, it interprets the "2" and "3" as Double at read time, since
integers cannot be divided and the defaults tell it to assume Double
rather than Rational).  (2::Rational)/3 gives the fraction 2/3
(printed as "2 % 3").

Ralf