RE: [Sml-implementers] Subject: Standard ML

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

Thanks, Andrew.  This is a nice summary of how I think we ought to proceed.
I agree that changes in category (D) are more delicate, and we should
certainly take pains to ensure that legacy code is not simply thrown
overboard.

Bob

-----Original Message-----
From: Andrew Kennedy [mailto:ak...@mi...]
Sent: Thursday, September 27, 2001 10:21 AM
To: Matthias Blume; sml...@li...
Subject: RE: [Sml-implementers] Subject: Standard ML


Matthias Blume wrote:

> Well, not having further changes will certainly create 
> perfect harmony: All users and all implementers will agree 
> perfectly (since there will be none). Unfortunately, it will 
> be the harmony one usually experiences only in graveyards...
> 
> (Sorry for sounding so depressed, but this discussion _is_ 
> depressing!)

Then let me try and bring some cheer to the discussion. This
is the first time I can remember a significant number of SML
implementers discussing the language in such detail at all.
Some points:

SML is not yet dead
-------------------
There are a surprising number of live implementations or 
nearly-ready implementations of the language:

(In no particular order)
Moscow ML, SML/NJ, TILT, Church Project, MLton, Poly-ML, 
MLj, SML.NET

I'd really like to see the "nearly-ready" implementations 
released (and here I include the "real soon now" version 111 
of SML/NJ). Such a breadth of implementations each with its 
own focus is surely a sign of life in a language.

Our proposals are modest
------------------------
Almost all of the proposals so far discussed come under 
one of the headings 

  (A) "matters not covered by the Definition of Standard ML", 
  (B) "mistakes in the Definition" or 
  (C) "changes to SML that don't break existing code". 

Here's a quick categorization:

  (A) Libraries, compilation management, FFI, the "top level",
      scope of flex-record/overloading resolution
  (B) Free type variables at top level
  (C) Structure sharing, vector expressions/patterns, or-patterns,
      higher-order functors, non-expansive raise, laziness,
      withtype in signatures, updateable records, polymorphic
      recursion

Finally, under the heading

  (D) "changes to SML that break existing code"

we have:

  (D) Removal of abstype, removal of equality polymorphism,
      fixing surface syntax problems, wraparound arithmetic
      
Unless one is really hard-line (implementations must be 
bug-for-bug compatible with the Definition) it's hard to argue
with (A) and (B). The danger with (C) is that each implementation
has its own ad-hoc extensions; then programmers write code that uses
the extensions and is therefore tied to a single implementation.
How about adopting the following procedures:

(1) Any extension first gets discussed on this mailing list. That
way we won't end up with multiple designs for the same feature. (Am
I right in thinking that this has already happened for higher-order
modules?)

(2) Ideally extensions should be specified in the style of the 
Definition, thus providing a solid reference for compiler writers.

(3) Compilers should have a compatibility mode in which extensions 
are rejected or deprecated. This could be controllable at the level 
of individual extensions.

(4) Where possible we should provide source-to-source translation tools 
that rewrite extensions as SML'97 code. A common parsing and 
layout-preserving pretty-printing infrastructure would be very helpful
here, but with it I believe that some of the proposed extensions can
be translated away (e.g. or-patterns, vector syntax, updateable
records).

Comments?
- Andrew.

_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers