RE: [Sml-implementers] extensions to SML

[David M. <Dav...@pr...>]

I've been thinking of how to respond to the suggestions for extensions
and changes to the language.  Most of all I've been trying to work out
why there is the desire for change.  What is it trying to achieve?  

It seems to me that there are three groups of people involved in SML who
may have different views on the desirability of change: language
designers, implementers and users.  Of course, in practice these groups
overlap and at various times I've been a member of each.  For a language
designer adding new features and making changes are the whole point of a
language.  A stable language represents a language with no interest.
For implementers change represents new challenges although it's possible
to find interest and challenges in finding novel ways to implement a
stable language.  Users are probably the most conservative of the
groups, especially users with a substantial investment in code.  For
them any change is probably a bad idea and if there has to be change it
must be done in such a way as to provide backwards compatibility.

I assume we are all in favour of encouraging the use of SML and the
differences are all in how best to achieve this.  Will we encourage more
use by "improving" the language, by giving them a better, cleaner
language to program in?  My feeling is not, that rather by making
changes we will discourage more users than we draw in.  Existing users
may decide that it's not worth going through their code adapting it to
the latest version of the language.  I feel that if we have to make any
changes to the language they should be minor changes which don't break
existing code.

There seem to be a number of interesting suggestions for language
changes and improvements being made.  It seems to me that the best way
of experimenting with them is in the context of a new language, freed
from the constraints of needing to be compatible with SML.  That isn't
to say that this will require starting from scratch.  Many of the SML
compilers are open source and if the new language is similar to SML it
should be possible to adapt an existing compiler to support the new
language.  Who knows, if the new language is successful we may end up
adapting all the existing SML implementations to support it?  We do,
though, have a duty to existing users not to disrupt their SML code.

David.