[MLton-user] language extensions
Wed, 29 Dec 2004 23:15:02 +0300
Stephen, does I understand you right: you would like to make MLTon SML
compliant. That's enough. All other features will be good, but it's
If so I will totally agree with you, because I suppose, that the more
developers will feel the taste of the language, the more efforts you
will get, and for that, in my humble opinion, IDE, debugger and good
documentation should be better helper.
Just my 2 cents...
On Dec 29, 2004, at 23:04, Stephen Weeks wrote:
>> Given that MLton is asymptotically close to 100% in SML standard
>> compliance and is rapidly approaching "fast enough". Does the MLton
>> team start to look outwards towards interesting extensions in Alice,
>> SML/NJ, Haskell, OCaml, Moby, ... as well as continued internal work
>> the compiler.
>> Or on the other hand if the "goal" is strict compliance to the SML
>> standard and within that context continue to improve the compiler to
>> levels of compiler wizardry...
> My personal goal is to enable programmers to be as effective as
> possible with MLton/SML. I think that changes to the language are
> *far* down the list of improvements that could be made in working
> toward that goal. To name some more valuable improvements off the top
> of my head, in no particular order: IDE support, and interpreter/REPL,
> fast incremental recompilation, library packaging and versioning, a
> debugger, more libraries, more platforms, ability to generate shared
> libraries, better documentation. And of course, there are still some
> situations where optimizer improvements would be nice :-). There are
> also a number of difficulties and drawbacks to language changes, which
> pushes them even further down on my list (and, admittedly, makes me
> rather dogmatic in rejecting them).
> I'm not saying I think that <insert-language-feature-here> would be
> useless or wouldn't help programmers. But I do feel that SML is a
> nice stopping point in the evolution of languages and that MLton/SML
> is a nice platform from which to explore the many other directions for
> making programmers effective.
> So, just as MLton is often fast enough, SML is often expressive
> enough, and the low-hanging fruit is elsewhere.
>> During the annual survey it would be interesting to know the core
>> team's particular inclinations.
> We'll get something in there. Thanks for the suggestion.
> MLton-user mailing list