From: Peter S. <se...@di...> - 2001-09-27 15:58:34
|
On Thu, 27 Sep 2001, Andrew Kennedy wrote: > Then let me try and bring some cheer to the discussion. I don't see anything to be depressed about either. > (C) Structure sharing, vector expressions/patterns, or-patterns, > higher-order functors, non-expansive raise, laziness, > withtype in signatures, updateable records, polymorphic > recursion Quotations and anti-quotations also belong in this category. SML/NJ, Moscow ML and the ML Kit (and probably Poly/ML and others) implement them, they behave exactly the same in those implementations, and they are disabled by default (as far as I know). Such agreement is what we must strive for. > 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 This collection of proposals was far more depressing and more dangerous to the health of SML. It is just unbearable for users (including myself) to have to apply `fixes' whenever we compile an existing program. Especially so since the change process would go on for years, given the number of radical proposals that were put forward. > (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?) The syntax for higher-order functors is different between SML/NJ and Moscow ML, yes. > (3) Compilers should have a compatibility mode in which extensions > are rejected or deprecated. This could be controllable at the level > of individual extensions. Moscow ML by default warns about all non-SML Modules extensions, and has an option -orthodox that rejects them outright. Peter |