# [MLton] Re: [Smlnj-dev-list] Evolving SML

Robert Harper rwh@cs.cmu.edu
Tue, 25 Oct 2005 23:39:18 -0400

a few quick thoughts in reply to the suggestions below, with more

1. we at cmu will very shortly circulate a separate compilation
proposal that includes two semantics, one based on the definition, the
other (which we actually use) based on the hs interpretation.  i am
hoping that we can agree on this proposal, or something very close to
it, as a standard.  our premise is that we want a language, not a tool,
for describing and building programs from separately compiled
components.  it supports both separate compilation and incremental
recompilation naturally and smoothly, so there should be no obstacle to
supporting it even under a whole-program model such as used in mlton.
we've been using it in tilt for years.

2. i don't like the macqueen-wadler proposal for laziness, which
inappropriately ties the concept to data types, but prefer something
more general, with syntactic support to make it convenient.  i believe
my proposal is consistent with an earlier one by chris okasaki, but i'm
not completely sure of that.

3. the current treatment of numerics is terrible and should be fixed.
morrisett has recently advocated making int be arbitrary precision
integer arithmetic, and have separate finite "integer" types for
special purposes that really want them and care about them.  what do
defaults, because we can obviously have libraries for both arbitrary
precision and bounded precision numbers, signed and unsigned, whatever
you like.

4. matthias blume should comment on what to do about an ffi.  it's
terrible not having this.

5. i have several suggestions for somewhat more substantial changes to
the language, in particular a proposal for re-working and generalizing
datatypes that i think has quite a few advantages over the current
setup.

6. we should consider adding support for (some form of) type classes
*as a mode of use of modules*.  ie, modules remain primary, with
so-called type classes being a convenience for some commonly occurring
patterns of usage of modules.  i consider it an entirely separable
question whether or not overloading is to continue to be supported in
is one way to use type classes, which are themselves a way to use
modules.

7. i have to page in the specifics, but i recall when working on pscico
that there were quite a few problems with floating point arithmetic,
not all of which were performance-related.  a pet peeve: the type
should be called float, not real!

8. i believe that there is disagreement about some of the signatures
(at least) in the basis library, or at least i'm sure i've heard people
say that there are problems.  one way or the other we should settle
these fairly quickly.

9. in some respects the (abstract) syntax promises more than it can
deliver, eg treating rec as a modifier to a val binding is a joke since
only a very restricted form of val binding can be recursive.  and the
stupidity of permitting val rec rec rec f = ... and rec g = ... and h =
... needs no further amplification.  i have suggestions for how to
clean this up.

a closing thought: it seems to me that we can do well by "stealing"
ideas from haskell and doing better overall by basing the language
solidly on modules (and, of course, cbv).

bob

On Oct 25, 2005, at 4:51 PM, John Reppy wrote:

> I think that this is a great idea.  In fact, as I was walking home
> yesterday
> I was drafting a proposal in my head for "\alpha{}ML" :).  I like the
> idea of
> structuring the process as addenda to the definition.  Here are a few
> ideas
> for short-term (and medium-term) features that I'd like to see:
>
> 	1. functional record-update syntax.  There is a partial
> implementation of
> 	   this feature for SML/NJ, but it hasn't made it out of CVS yet.
>
> 	2. standardization on integer types.  I'd like to see implementations
> agree
> 	   to support 32-bit, 64-bit, and arbitrary precision integers, and to
> 	   agree on what the type "int" means.  I think that the biggest
> mistake
> 	   we made in the Basis design was failing to standardize on a fixed
> 	  set of well-defined numeric types.
>
> 	3. or-patterns (SML/NJ has supported these since '92 or '93)
>
> 	4. conditional patterns.
>
> 	5. an standard notation for specifying the build process, so that
> libraries
> 	   would be portable.
>
> 	6. a standard low-level mechanism for specifying FFI.  Ssomething
> like the
> that
> 	   tools like nlffigen can target.
>
> 	7. records with mutable fields.
>
> 	8. standard support for lazy evaluation.  Wadler and MacQueen's
> proposal
> 	   is a good starting place.  Supporting lazy fields in records might
> be nice.
>
> 	9. polymorphic recursion.
>
> 	10. a standard model of concurrency.
>
> 	- John
>