Main Page

From Successor ML

Contents 1 Successor ML 2 News 2.0 2015/07/31 2.1 2009/09/09 2.2 2008/05/09 2.3 2008/04/16 2.4 2007/03/23 2.5 2006/09/18 2.6 2006/09/17 2.7 2006/09/10 3 The Discussion so far 3.1 Immediate 3.2 Short-term 3.3 Medium-term 3.4 Long-term 3.5 Libraries 4 Proposals 5 Implementations 6 Logo

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.

News

2015/07/31

The old Successor ML wiki pages have been recovered from the internet archive and have been posted on the SML Family Github site. Note that while these pages appear to be a WikiMedia server, they are, in fact, a static snapshot from December 2014.

2009/09/09

An alpha release of the Mechanized Definition of Standard ML is now available. Perhaps this will reignite interest in a Successor ML.

2008/05/09

Added captchas. Hopefully this will help cut down on spam.

2008/04/16

Upgraded Mediawiki installation.

2007/03/23

Added a link to HaMLet-S.

2006/09/18

Created stub pages for Harper-Stone Semantics and ML2000 Principles.

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.

2006/09/17

Link for the Harper-Stone Semantics and for Principles and a Preliminary Design for ML2000 papers.

2006/09/10

The 2006 ACM SIGPLAN Workshop on ML will be co-located with ICFP 2006 in Portland, Oregon and held on September 16, 2006. The list of accepted papers is online.

The Discussion so far

A very cursory summary from the sml-evolution mailing list:

Immediate

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
• Quoting/anti-quoting

Short-term

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?

Medium-term

Changes that still require research and experimentation, or break large portions of existing code.

• Views
• Use (. ... .) 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?
• GADTs?
• Recursive modules?
• A more expressive signature language?
• Proof obligations
• A sML-IL?

Long-term

Extensions that are desirable but we do not know how to achieve them well yet.

• An effect system

Libraries

Changes that are not to the language per se, but the accompanying standard library.

• What should int be?
• Rename real to float?
• Basis library changes
• More data structures, e.g. from SML/NJ lib?
• Unified foreign function interface?

Proposals

• Separate Compilation

Implementations

• HaMLet-S is intended as a testbed for experimentation with changes and extensions for sML and incorporates a number of the proposals listed above.

Logo

As is rather obvious, a spiffy logo could be used. Upload candidates and post them on the sML Logo page.