RE: [Sml-implementers] extensions to SML

[Robert H. <Rob...@cs...>]

I would eliminate equality polymorphism entirely.

Bob

-----Original Message-----
From: Stephen Weeks [mailto:sw...@in...]
Sent: Friday, September 14, 2001 7:03 PM
To: sml...@li...
Subject: [Sml-implementers] extensions to SML



Sorry for changing the thread name.  Here's my 2 cents.

One way find out what SML needs is to look at what extensions current
implementations make, which were presumably added because of a need.  In
doing
so, one can get some feel for the importance of standardizing an extension
by
looking at how many implementations have some variant of it.  Using this
metric,
here is my list of extensions to standardize, in decreasing order of
importance.
(I am mostly familiar with MLton and SML/NJ, but have dabbled with the ML
Kit,
Moscow ML, and Poly/ML.  So, this list is somewhat biased.) 

* decent library
* compilation management
* FFI
* higher-order functors
* other tweaks to the type system

I rate the importance of a library at least an order of magnitude above
the rest.  I rate higher-order functors and other type system tweaks another
order of magnitude down.

For compilation management, I would like to see explicit dependency
information,
as well some support for managing the module level namespace (a la CM).  If
people want to build tools that generate the dependencies, fine.

I'm not sure what to argue for in an FFI, since that seems to be an area of
active research, but it sure would be nice to standardize something, if even
a
simple subset.

As to some of the specific tweaks mentioned by others, my feelings are to
reject
any incompatible change, unless it is wrong in the current definition, or
excessively complicates the definition and is unused.  Here are a few
specifics.

* dropping local
  I strongly argue against dropping local.  It is not complex or
problematic,
  and dropping it will break old code.  For example, there are over 300 uses
in
  MLton. 

* dropping eqtypes
  I don't strongly object to this.  But I am very wary of any incompatible
  change.  Also, I wanted to make sure that people weren't also thinking
about
  dropping polymorphic equality, which is essential in some cases.

* dropping overloading
  Overloading as it stands is not hard to reason about and is useful.  And
  dropping will break a lot of programs in a lot of places.

* dropping sharing
  I would find dropping sharing devastating, unless it could be simulated
with
  "where", without much syntactic change.

To repeat my main point -- I don't think any of the type system changes or
language extensions mentioned in earlier emails are fixing the main problems
with SML, which are: the lack of a decent standard library, the lack of
standard
FFI support, and the lack of a standard way of managing large programs.

_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers