RE: dynamic vs. static typing

["Anton van Straaten" <address@hidden>]

Peter van Rooijen wrote:
> You are comparing languages with and without early typechecking.
> You are comparing the stage of development at which, in each
> language, the type errors are going to manifest themselves.
>
> Implicitly, you are assuming that the type errors that will
> occur are the same (or so alike that the difference is of no
> importance). Do you agree that you are implicitly assuming
> that?

Yes, I agree, more or less.  There are large classes of error that have
close equivalents across many general-purpose languages, regardless of their
paradigm or typing discipline.

> Is it intended?  If it is intended, do you really believe that
> on these different languages, essentially the same type errors
> will be coded into the programs?

Yes, essentially.

> Related question: Do you believe that the nature of type errors in both
> language categories is essentially the same?

There may be some unique aspects in some languages that don't have
reasonable equivalents in other languages.  But in general, most
general-purpose languages ultimately perform very similar operations of
abstraction, variable binding, and application of methods/functions, all of
which are subject to similar classes of error.  Beyond that, many languages
have the ability to define entities with interfaces that are subject to
similar errors, whether those entities are conceptualized as classes, or
types, or records, or whatever.

> If you do believe that, what are your reasons? I'm not asking
> for your evidence, I don't care about that :-).

Perhaps enumerating some simple errors that tend to apply across languages
and can be detected statically would help:

* misspelled variable names
* arguments to functions of the wrong type
* assignments to variables of the wrong type (a special case of the previous
point if you model variable binding as applications of lambdas)
* a whole range of interface non-compliance issues:
  * attempting to use an interface that is not supported by the value being
used
  * attempting to use a non-existent member of an interface
  * creating derived types or classes which don't conform to constraints
imposed by the base entity

> [Note: My own experience with the dynamically typed language Smalltalk,
> leads me to think that type errors, inasfar they manifest themselves as
> errors, are of a rather different nature than the kind of errors type
> checkers find.]

I'd need some examples to be able to comment.  I've used Smalltalk a bit,
studied it somewhat, and done a lot of work with other dynamically typed OO
languages, including implementing a minor commercial DT OO language product.
All of the points enumerated above have direct equivalents in such
languages.

> One of the things I don't like about Smalltalk is that there is
> quite some information that I know when I'm coding, but don't
> (can't) tell the program about.

This is one of my big objections to "pure" dynamic typing.  If there's
information that I want to be able to express in my program, that I can't
reasonably express, that's a limitation that I don't like.

> Then later, when someone reads the code, it is more difficult
> to understand my intention than if I had been able to put that
> information in the program, and when I made a mistake, it is
> more difficult for the execution engine to guess what my mistake
> might have been.

Sure.

> If the language offered me the opportunity to (formally) express
> some of this information that I currently can't put in, I would
> of course like the system to check whether I was inconsistent in
> what I expressed, and tell me as soon as it could detect that
> inconsistency ("I don't care if you call it static, dynamic or
> whatever: I just want it checked ASAP").

Precisely.

> [Note: Sometimes the information I cannot express, but would like
> to (and would like to have checked for consistency), is about the
> types of variables or functions.

I'm sure I'm missing something here, but that's exactly what any static type
system allows.

> This is especially the case when the type is a basic one, such
> as integer, number, or boolean. More often, the information is
> about the type of operations (which imply their semantics). I've
> never seen a language that allows me to specify that. Anyone?]

I'm not sure what you're getting at.  Can you give an example?  If you want
something that acts like a basic type but has a restricted or augmented set
of operations or values, then you're talking about an abstract data type,
which in ST languages tend to support type checking very well.  You're
probably thinking of something else, though.

Anton