Re: [polyml] From SML/NJ to Poly/ML

[Michael Moeller]

Please allow me a few words of caution on standardisation and new features. Talking about this matter while implementors even don't agree on the number of bits a word has is quite funny. By the way, I don't know about the requirements mathematicians have or what they expect from ML but from my industrial point of view almost everything is non-standard. The whole machinery runs on proprietary software. There are interfaces to Java, if you are lucky. So what's the deal with standardisation? We have to distinguish between libraries and the core language. In general the core of a programming language is well thought. It is build on a paradigm which makes the language (hopefully) unique and often suitable to accomplish a certain task. Otherwise I might pick any. By adding 'yet another feature' which almost always is some kind of library, things get blurred and flatted out. Attempts to turn special languages into multi purpose ones are without number and seldom really convincing. Although 'features' are in vogue, SML is well advised to resist. Of course it's nice Poly/ML connects to the net, for example. On the other hand I won't like to see it choked by tons of libraries turning a small nice language into a bloated software monster which can do everything. It surely is a matter of taste what's worth to be kept in a new library and what's up to the programmer. Keeping things clean and simple never did any harm. Think twice before proposing a new feature an experienced programmer is able to develop by himself easily. I never took some kind of 'industrial grade' stress test on Poly/ML (although this would be interesting), but after all the years of its existence I don't expect it to have serious issues when applied to the problems it was made for. I won't recommend making alterations to the core language, unless it's inevitable by some reason. Regards, Michael Am 08/24/2012 12:12 PM, schrieb Lawrence Paulson: I personally would welcome a renewed effort to update Standard ML. Successor ML is clearly dead (better than Standard ML, which is ironic given its rather arrogant manifesto), but a small group of well-organised people might be able to put together some modest and well-thought-out revisions to the language. But I don't think that making ad hoc changes to Poly/ML would be a great idea. Larry On 23 Aug 2012, at 14:34, Ramana Kumar <ramana.ku...@gmail.com> wrote: I believe Successor ML (http://successor-ml.org) is a reasonable route for proposing and discusing language extensions. As far as agreement and standardisation goes, it's usually better if the language features are implemented and tested and used and appreciated before they are codified into (normative) standards. Thus it would make sense for compiler implementors to support extensions to the current standard as long as they are hidden behind compiler flags or pragmas or something. This doesn't mean such extensions shouldn't start life as descriptive standards/specifications, which many compiler writers may or may not choose to implement experimentally. On Thu, Aug 23, 2012 at 1:11 PM, Lawrence Paulson <l...@cam.ac.uk> wrote: I'd prefer to see no language extensions at all, except by agreement among the sml community as a whole. --lcp On 23 Aug 2012, at 13:02, David Matthews <david.matth...@prolingua.co.uk> wrote: > Over the years I've taken quite a strong line against extensions.  The > intention is that Poly/ML follows the Definition of Standard ML > (Revised) i.e. ML97.  That isn't to say that I couldn't be persuaded > otherwise but I think it would require more than this. _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml _______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml