From: Andrew K. <ak...@mi...> - 2001-09-27 14:23:11
|
Matthias Blume wrote: > Well, not having further changes will certainly create=20 > perfect harmony: All users and all implementers will agree=20 > perfectly (since there will be none). Unfortunately, it will=20 > be the harmony one usually experiences only in graveyards... >=20 > (Sorry for sounding so depressed, but this discussion _is_=20 > 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=20 nearly-ready implementations of the language: (In no particular order) Moscow ML, SML/NJ, TILT, Church Project, MLton, Poly-ML,=20 MLj, SML.NET I'd really like to see the "nearly-ready" implementations=20 released (and here I include the "real soon now" version 111=20 of SML/NJ). Such a breadth of implementations each with its=20 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=20 one of the headings=20 (A) "matters not covered by the Definition of Standard ML",=20 (B) "mistakes in the Definition" or=20 (C) "changes to SML that don't break existing code".=20 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 =20 Unless one is really hard-line (implementations must be=20 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=20 Definition, thus providing a solid reference for compiler writers. (3) Compilers should have a compatibility mode in which extensions=20 are rejected or deprecated. This could be controllable at the level=20 of individual extensions. (4) Where possible we should provide source-to-source translation tools=20 that rewrite extensions as SML'97 code. A common parsing and=20 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. |