From Successor ML
Standard ML, being incapable of evolution, is dead. The purpose of successor ML, or sML for short, is to provide a vehicle for the continued evolution of ML, using Standard ML as a starting point. The intention is for successor ML to be a living, evolving dialect of ML that is responsive to community needs and advances in language design, implementation, and semantics.
An alpha release of the Mechanized Definition of Standard ML is now available. Perhaps this will reignite interest in a Successor ML.
Added captchas. Hopefully this will help cut down on spam.
Upgraded Mediawiki installation.
Added a link to HaMLet-S.
On September 17, 2006 there was an informal meeting on the evolution of Standard ML held in Portland, Oregon prior to the start of ICFP 2006. If you have notes from the meeting, please create or extend a page.
The Discussion so far
A very cursory summary from the sml-evolution mailing list:
Changes and cleanups that are simple and do not cause relevant incompatibilities, i.e. there are no excuses not to do them now.
- Line comments
- Escapes in strings
- Extended syntax for literals
- Functional record extension and row capture
- Functional record update
- Record labels as fields
- Disjunctive patterns
- Generalizing layered patterns to conjunctive patterns
- Match guards
- Simplifying val rec syntax
- withtype in signatures
- Fixed scoping for manifest type specifications
- Degrade abstype to derived form
- Haskell-like declaration prototypes/signatures
- Optional bar before first match clause
- Disallow non-exhaustive patterns in polymorphic bindings
- More liberal type sharing
- "where" constraints for structures
- Drop "and" in "where type" constraints
- Derived "do" declarations
- Fixing various minor issues with the formal syntax
- Fixing various minor issues with the formal semantics
Changes that are more substantial but well understood. May break some programs or implementations.
- Unicode support
- Javadoc style comments?
- Improve grammar so fewer parens are required?
- Eliminate ref patterns? (mark as non-exhaustive?)
- Mutable records?
- Polymorphic recursion?
- Sharing constraints vs. n-ary where type clauses?
- Higher-order modules?
- Unified compilation/build technology?
Changes that still require research and experimentation, or break large portions of existing code.
(. ... .)for comments rather than
(* ... *)and/or use
# ...for line comments?
- Re-think syntax?
- Weakening the value restriction?
- Higher-order polymorphism and type constructors?
- First-class polymorphism?
- Existential (data)types?
- Polymorphic records?
- Polymorphic variants?
- Type classes or an otherwise improved overloading mechanism? (esp. to replace equality types)
- Data signatures?
- Recursive modules?
- A more expressive signature language?
- Proof obligations
- A sML-IL?
Extensions that are desirable but we do not know how to achieve them well yet.
Changes that are not to the language per se, but the accompanying standard library.
- What should
- Basis library changes
- More data structures, e.g. from SML/NJ lib?
- Unified foreign function interface?
- HaMLet-S is intended as a testbed for experimentation with changes and extensions for sML and incorporates a number of the proposals listed above.
As is rather obvious, a spiffy logo could be used. Upload candidates and post them on the sML Logo page.