Re: [Caml-list] Dynamic vs. Static

[Patrick M Doane <patrick@watson.org>]

The compelling argument to me in this paper is the example regarding
collections and Java.  The type for the method

  public boolean AbstractCollection::removeAll(Collection c)

is obviously too restrictive.  The argument in favor of it was to reduce
the number of interfaces in the standard library.  There is good reason
for limiting this in Java because subtyping is directly related to
inheritance.  To introduce a new interface would require figuring out how
to compose all of these pieces together.

Caml doesn't suffer from this particular problem because subtyping is not
related to inheritance. It would be trivial to create a new class type
that is used in various type signatures that specify exactly the set of
methods that are required.

C++ templates have a similar kind of freedom in that the types in that the
types needed to compile a function are inferred directly from the
definition of that function.

The problem with a system like C++ and also with the dynamic approach (as
far as I know - please correct me if this is wrong) is that there are
times when it is useful to constrain a type by more than what is required
for a particular implementation.  I've seen several cases of STL container
objects in C++ that work for one implementation of the standard algorithms
but fail to work with a different implementation.  Now the author had made
a mistake with respect to the documentation, although everything was legal
from the compiler's viewpoint.

It's also worth noting that, for whatever reason, Caml does not have a
very good collection library. The modules indivually are quite good but
they lack the unification that allows a developer to easily plug in a new
implementation as needed.

Patrick


On Fri, 9 Nov 2001, Eric Newhuis wrote:

> Would anyone care to read this and comment on it w.r.t. Caml/ML/etc?
>
> http://wiki.cs.uiuc.edu/VisualWorks/Mark+Fussell+Dynamic-vs-Static+Typing+Message
>
>

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr