[MLton] Evolving SML

[Matthias Blume]

My apologies if you receive this multiple times.  (I was not sure how  
up-to-date
the subscription list of sml-implementers is.)  If you know of anyone  
who should
see this message but has been left out from the list of recipients,  
then, please,
pass it on!

The main part of the message follows below.  A big "Thank you!" to  
Andreas for
drafting it!

Kind regards,
Matthias

------------------------------------------------------------------------ 
-

Dear fellow SML implementers!

Following up the ML Workshop at ICFP, we would like to reactivate the
awfully stagnant discussion about the future of SML. We strongly
believe that evolution is crucial for survival of a language. And SML
should not be considered dead yet!

Ignoring politics for a moment, one problem in the past discussions
was the lack of consensus about the direction and extend of possible
changes. In order to focus the discussion, we would like to suggest a
three-stage roadmap:

* Short term: fixing obvious deficiencies in the current language
   specification and conservatively extending it with modest, well-
   understood features. Possible goals for this round could be fixes to
   the Definition, a pragmatic solution to the separate compilation
   problem, and frequently requested additions like disjunctive  
patterns,
   "withtype" in signatures, or improved structure sharing.

* Medium term: overhauling the language and its specification,
   incorporating more ambitious extensions and possibly incompatible
   design cleanups. The Harper/Stone formulation and Bob's ongoing work
   on mechanizing it seem like a good starting point for this
   branch. Advanced additions, like higher-order modules, are probably
   best addressed at this stage.

* Long term: designing the "next ML". All not yet concrete visions
   for a YML or ZML - like sexy types, type classes, effects, or
   concurrency - go here.

To get something moving at all, we would like to concentrate the
discussion on short term development for now. Having the Definition
and its formal framework as a firm foundation, a community effort
appears to be a viable approach to moderately adjust and evolve the
language.

How could we proceed?

It is clear that we want to stay with the foundational spirit of the
language and only adopt changes for which we have a formal
specification.  Since we may neither change the Definition, nor the
meaning of "Standard ML", we propose specifying and publishing changes
as "deltas" to the Definition. Once we agree on a particular set of
changes we may combine them into a comprehensive "addendum" and refer
to the resulting language as, say, X::SML - "Some ML with eXtensions"
;). We expect the process to be incremental and open, and leave room
for further Xi::SML versions.  Better suggestions are welcome.

We would prefer to go without an overly regulated proposal and voting
process and rather have an open mode of discussion. Our community is
small enough and our goals sufficiently moderate to hope for consensus
on most issues. We could still consider adopting a more bureaucratic
approach if that turns out to be unworkable.

Intended changes and extensions are best made and discussed informally
on the implementers list. Before a change can be accepted, it has to
be written up as a formal proposal, though. We suggest that such
proposals include the following:

1. A classification (bug resolution vs. extension).
2. A rationale.
3. A precise formulation in form of a delta to the current Definition.
4. A brief analysis of possible implications on properties of the
    language, its implementations, and existing programs.

Moreover, we probably should require it to be implemented in at least
one SML system before acceptance.

Making the whole effort successful requires somebody to coordinate it,
to push and controll the process, and to have the final editorial
word.  Ideally, this should be an authoritative SML `senior'. Finding
a volunteer would probably be our first task.

We urge everybody to join the discussion. Do you share our interest in
evolving SML? Would you be willing to commit your time and energy to
it? Do you think the approach we sketched is appropriate? Do you have
concrete suggestions regarding its organisation?

To the outside, SML sometimes makes a devastating impression in terms
of community and activity. If we want to counter that it seems
important to demonstrate some progress as soon as possible. In our
opinion, the best-suited strategy for an "X1::SML" is to first
concentrate on low hanging fruits and get them out of the door
soon. Hopefully, it creates some helpful momentum for turning to more
difficult or controversial points.

Matthias Blume & Andreas Rossberg