RE: dynamic vs. static typing

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

On 26 Nov 2003, at 7:27 PM, Peter van Rooijen wrote:
> I'm talking about the situation, which is very common for me, that I
> have something extra I would like to say (in code), about the message
> I am sending, while I might not have anything I'd like to say about
> the variable I'm sending the message to.
>
> For instance, I might want to send #size to myObject (in
> Smalltalk: myObject size), and I know that I mean #size as in
> "the number which is the same as the number of objects that
> would be enumerated if I did an enumeration". So, the #size
> I am sending is #size with the semantics as defined in the
> Enumerable type.
>
> In fantasy-Smalltalk, I would perhaps write myObject Enumerable#size.
> Important to note here that this is not a cast of the expression
> referencing the variable; I am NOT ready to say anything about the
> type of the variable myObject. It could be anything. I'll probably
> attach a collection to it (and the collections I'm going to attach
> are certainly going to be enumerable), but I'll decide later and
> I might change my mind. I might never provide a type for myObject.
> But I do know that right here I want Enumerable#size.
>
> Maybe this sounds really strange. Maybe it is :-).

No, it's not strange at all.  What you are describing are interfaces or
typeclasses, terminology depending on language.  Their exact behavior
depends on the language/typesystem.  Your fantasy-Smalltalk is actually
suspiciously similar to Java.

You say that "I am NOT ready to say anything about the type of the variable
myObject", but really that's incorrect.  You *are* making an assumption
about the type of the variable: you are assuming that it will refer to an
object that supports an Enumerable interface.  The object may also support
other interfaces, but that's OK, if you have a good type system.

A number of languages implement such interfaces explicitly in some form.  In
Java, they're called interfaces.  In Haskell, the equivalent is typeclasses.
C++ also supports them.  Those are all statically typed languages, but some
dynamically typed languages support them also, including some Scheme object
systems.  Even (some) Smalltalks have them:
http://wiki.cs.uiuc.edu/VisualWorks/SmallInterfaces

Unfortunately, traditional class-based OO tends to encourage a mindset in
which the type of an object is considered to be equivalent to its class.
Since class inheritance is often chosen for implementation reasons, this
results in conceptual design errors in which the type of an object is
thought to be constrained by its specific place in the class hierarchy -
e.g., if an object in the above example doesn't inherit from an Enumerable
class, it's often assumed that it cannot be of type Enumerable.  This was a
horrible mistake in the history of OO, which sadly is still being
perpetuated by many languages today.  Luckily, there's a bit more awareness
of it, partly because of the languages that offer better solutions, but also
because OO design has become more entrenched as a discipline in its own
right, somewhat independent of languages.

In most real program, most of the time, you have a pretty definite idea of
the *interface* you expect of the objects you're sending messages to.  If
you don't, there's a problem: unless you're going to program an entire
system through some equivalent of 'doesNotUnderstand', why would you send a
message to an object without knowing that it can respond appropriately?

In practice, this means that most languages could support and benefit from
type annotations, without losing any expressiveness.  As discussed in an
earlier thread, it's the opposite case that's unusual: dealing with objects
for which you have no idea of the interfaces they support.  Programs in
dynamically typed languages are rife with assumptions about types that could
be encoded in the program, without losing anything.  This encoding is not
done mainly because of limitations in the language.

> I have never heard of this latter kind of typing (operation
> typing, message typing, semantic typing), and don't know if
> there exists a name for it. If anyone knows of any material
> or research about this way of annotating, please let me know.
> I want to add this type of annotation to a language I'm
> designing and would like to benefit from existing research
> if it exists.

Look at interfaces in Java, and typeclasses in Haskell, and the above
Smalltalk link, for a start.  One paper on the subject is this:
http://citeseer.nj.nec.com/hall96type.html
...but it's focused more on the type inferencing issues.  You might be more
interested simply in learning about use of the language features in
question, perhaps via tutorials or language reference manuals.  Coming from
Smalltalk, it might be easier to get into Java than Haskell - you can think
of Java as a sort of statically-typed Smalltalk.

> There was also an incompleteness/partialness criticism about
> variable/function typing which was somewhat implicit in this
> point, which is that when I want to specify a type, it is
> only the type of a variable or function in a relatively
> small percentage of cases, and then mostly when they are
> the more mundane types. When using domain-specific objects,
> I'll more often have something to say/declare/annotate about
> the semantics I am expecting of the operations that get
> invoked (and I would like to get those checked). And I've
> never seen support for that other than by > being forced to
> type a variable/function first.

Not quite sure what you're saying.  However, with the interface or "type
class" notion, the same object can support more than one interface or type
class.  Depending on what you're doing with a value, you would use variables
declared appropriately (assuming explicit declarations are needed, as
opposed to inferencing).  You may also use multiple different variables,
declared as being of different interfaces/typeclasses, but have them refer
to the same object.

Anton