Optional Static Typing - Haskell?

[Alex Martelli]

Donn Cave <donn at drizzle.com> wrote:
   ...
> | making a really modular system work with static typing and inferencing
> | is probably impossible; in practice, the type inferencer must examine
> | all code, or a rather copious summary of it... it can't really work
> | module by module in a nice, fully encapsulated way...).
> 
> Well, I would assume that a modules in a static system would present
> a typed external interface, and inference would apply only within the
> module being compiled.
   ...
> There might be tricky spots, but I imagine the Objective CAML
> folks would object to an assertion like "making a really modular
> system work with static typing and inferencing is probably
> impossible"!

It seems to me that you just restated in the first part I quoted what
you say in the second part OCAML folks would object to.  If you give up
on type inferencing across modules, and only have type inferencing
inside each module, then you're getting little mileage out of the
inferencing if your modules are many and small.

But let me quote Van Roy and Haridi, rather than paraphrasing them, lest
I fail to do them justice -- I think quoting 8 lines out of a book of
over 800 pages is "fair use" (anecdote: my Xmas gift is said book, my
wife's a real-bargain Powerbook 15" Titanium laptop -- yesterday we
weighed them against each other and determined the book's heavier;-)...

"""
Dynamic typing makes it a trivial matter to do separate compilation,
i.e. modules can be compiled without knowing anything about each other.
This allows truly open programming, in which independently written
modules can come together at runtime and interact with each other.  It
also makes program development scalable, i.e., extremely large programs
can be divided into modules that can be recompiled individually without
recompiling other modules.  This is harder to do with static typing
because the type discipline must be enforced across module boundaries.
"""

I see that by paraphrasing and summarizing by heart I was changing their
argument a bit, from 'enforcing the type discipline' (which is what
they're discussing, and is obviously mandatory if you want to talk about
static typing) to 'type inferencing' (which they don't discuss in this
specific paragraph).  Nor do they claim 'probably impossible', since
they're only discussing enforcement, not inferencing -- just 'harder'.

Essentially, to compile a module under static typing you need full type
information for other modules -- the "without knowing anything about
each other" condition of fully separate compilation can't hold, and thus
neither can the "truly open programming" and "scalable development"
consequences.  Mind you, I personally _like_ the concept of describing
an interface separately, even in a different language (Corba's IDL, say)
that's specialized for the task.  But it doesn't seem to be all that
popular... without such separation, modularity plus static checking
appears to imply bottom->up coding: you need to compile modules in some
topologically sorted order compatible with the "X uses Y" relation.


Alex