[Sml-implementers] Developing ML

[Robin M. <Rob...@cl...>]

I've read most of the recent discussion (various people have kindly
copied or forwarded messages to me, as I'm not a regular member of the
list).  It's clear that there is considerable interest in advancing -
or advancing from - SML.  Andrew's and Bob's categorisations show that
the range of topics to look at is multi-dimensional.  I agree with
those who say that languages evolve.  My view, expressed in a joint
message with Mads Tofte, is that we need evolution _from_ SML, but not
evolution _of_ SML.  I want to explain this position.  Mads has
recently been both an implementer and a user, which I haven't, so he
may well explain it differently.

The SML project was conceived as an ambitious attempt to bridge the
gap between real-world programming and fully formal language
definition.  To succeed, we had at least to show that rigorous
definition would actually confer benefit on programming practice. In my
view we did succeed; the unambiguity of the semantics made it
absolutely clear what users were getting, its near-determinism made
porting of programs between implementations reasonably feasible, and
its stability over many years relieved implementers of at least one
kind of headache.  The need to make a complete definition also
clarified the language design.  So we can claim to have made it more
reasonable for real languages to aspire to a formal semantics.

Of course the project had a tension built into it from the start,
between the rigour required of a formal definition and the freedom to
evolve.  The success hasn't resolved the tension, but made it more
visible.  In fact, there seem to be two tensions; one (#1) between the
wish for evolution and the need for stability (which can only partly
be solved by backward compatibility) and another (#2) between the
evolution of a language and the evolution of its semantics.

I think implementers have differing views on how to resolve tension
#1, i.e. how to weigh evolution versus stability, and this fact is
part of the reason for my position.  If you evolve (the Definition of)
the language itself, then you abandon a stable platform; if you evolve
_from_ the language then you preserve the platform and allow true
evolution - i.e. different paths and different speeds of development.

But tension #2 is also part of the reason for my position, and I want
to say more about it because nobody has said much.  There is a
mismatch between our ability to evolve programming language (which
runs pretty close to our ability to evolve natural language) and our
ability to adapt formal definition accordingly.  Although people know
a lot more how to write semantics than 20 years ago, we don't yet know
how to do it in a way which supports change easily. (This is a
specific and difficult instance of formulating software specifications
which support change.)

 Take the '97 revision of SML as an example.  We aspired to a modest
set of changes, and yet to bring the formal definition in line with
them was a large task in proportion; Mads Tofte and I wrote most of
the `code' of the Definition and we probably understand this more than
most. The result wasn't perfect; I trust the '97 Definition more in
some respects, but less in others respects, than the '90 semantics.

Why is it difficult to adapt a formal definition to change?  In
undergraduate lectures on "Designing and Defining a Language" I point
out that every worthwhile language juxtaposes features which are well
understood separately but not understood in juxtaposition.  (If they
were, the language would exist already.)  A good example is the
interaction (not originally understood) between updating (understood)
and simple polymorphism (understood).  These interactions are
reflected by non-orthogonalities in the semantics which in turn render
the semantics vulnerable under change; relatively small changes in
language can permeate large parts of the formal definition, and thus
degrade confidence.
  
Bob says "IMO the 1997 revision was hobbled by an excessive emphasis
on the needs of The Definition without due consideration of
implementation or application."  My view is quite different.  True,
because of the need to get a sound definition with limited available
effort, we knew we could only afford to address a few changes (because
of the permeation phenomenon).  But the "needs of the Definition"
arise precisely from a concern for implementation and users, because
of the benefits which sound definition confers.

If you're still with me, let's go back to tension #2, between evolving
a language and evolving its definition.  I've argued that the latter
is (a) harder and/or slower, and (b) liable to degrade quality.
Putting this together with my remarks about tension #1 (between
evolution and stability), I am convinced that Standard ML should
remain as it is; a reasonably solid platform from which different evolution
paths (of even just a single path if there is consensus) of language
can be taken.  Therefore I would not accept an evolution _of_ Standard
ML itself.

Far from killing or ossifying ML, this liberates it.  This is because
(a) different paths can be taken, with names which reflect membership
of the ML family; and (b) these paths can be followed either with or
without providing formal semantics, or perhaps exploring different
semantic methods (e.g. type-theoretic).  One natural path would be a
short one, identifying a set of alleged shortcomings in SML and
proposing improvements, with (as Andrew suggests) semantics in the
style of - and with reference to - the '97 SML Definition.  It could
be called - say - ML2002; not being called SML there is no need for
complete consensus on this path, and indeed some implementers and
users may well prefer to stay with SML.  

If there's one thing that the SML development over the last 18 years 
has shown, it is that consensus is a luxury!

Robin Milner