[Sml-implementers] Re: [Smlnj-dev-list] Evolving SML

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

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

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 
people think about this?  remember, it's entirely a question of the 
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 
any form --- type classes are not about overloading, rather overloading 
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
> 	   Haskell FFI layer (http://www.cse.unsw.edu.au/~chak/haskell/ffi/) 
> 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
>