[hcoop/debian/mlton.git] / doc / guide / src / LanguageChanges.adoc

LanguageChanges
===============

We are sometimes asked to modify MLton to change the language it
compiles.  In short, we are conservative about making such changes.
There are a number of reasons for this.

* <:DefinitionOfStandardML:The Definition of Standard ML> is an
extremely high standard of specification.  The value of the Definition
would be significantly diluted by changes that are not specified at an
equally high level, and the dilution increases with the complexity of
the language change and its interaction with other language features.

* The SML community is small and there are a number of
<:StandardMLImplementations:SML implementations>.  Without an
agreed-upon standard, it becomes very difficult to port programs
between compilers, and the community would be balkanized.

* Our main goal is to enable programmers to be as effective as
possible with MLton/SML.  There are a number of improvements other
than language changes that we could spend our time on that would
provide more benefit to programmers.

* The more the language that MLton compiles changes over time, the
more difficult it is to use MLton as a stable platform for serious
program development.

Despite these drawbacks, we have extended SML in a couple of cases.

* <:ForeignFunctionInterface: Foreign function interface>
* <:MLBasis: ML Basis system>
* <:SuccessorML: Successor ML features>

We allow these language extensions because they provide functionality
that is impossible to achieve without them or have non-trivial
community support.  The Definition does not define a foreign function
interface.  So, we must either extend the language or greatly restrict
the class of programs that can be written.  Similarly, the Definition
does not provide a mechanism for namespace control at the module
level, making it impossible to deliver packaged libraries and have a
hope of users using them without name clashes.  The ML Basis system
addresses this problem.  We have also provided a formal specification
of the ML Basis system at the level of the Definition.

== Also see ==

* http://www.mlton.org/pipermail/mlton/2004-August/016165.html
* http://www.mlton.org/pipermail/mlton-user/2004-December/000320.html
Commit	Line	Data
7f918cf1 CE	1	LanguageChanges
	2	===============
	3
	4	We are sometimes asked to modify MLton to change the language it
	5	compiles. In short, we are conservative about making such changes.
	6	There are a number of reasons for this.
	7
	8	* <:DefinitionOfStandardML:The Definition of Standard ML> is an
	9	extremely high standard of specification. The value of the Definition
	10	would be significantly diluted by changes that are not specified at an
	11	equally high level, and the dilution increases with the complexity of
	12	the language change and its interaction with other language features.
	13
	14	* The SML community is small and there are a number of
	15	<:StandardMLImplementations:SML implementations>. Without an
	16	agreed-upon standard, it becomes very difficult to port programs
	17	between compilers, and the community would be balkanized.
	18
	19	* Our main goal is to enable programmers to be as effective as
	20	possible with MLton/SML. There are a number of improvements other
	21	than language changes that we could spend our time on that would
	22	provide more benefit to programmers.
	23
	24	* The more the language that MLton compiles changes over time, the
	25	more difficult it is to use MLton as a stable platform for serious
	26	program development.
	27
	28	Despite these drawbacks, we have extended SML in a couple of cases.
	29
	30	* <:ForeignFunctionInterface: Foreign function interface>
	31	* <:MLBasis: ML Basis system>
	32	* <:SuccessorML: Successor ML features>
	33
	34	We allow these language extensions because they provide functionality
	35	that is impossible to achieve without them or have non-trivial
	36	community support. The Definition does not define a foreign function
	37	interface. So, we must either extend the language or greatly restrict
	38	the class of programs that can be written. Similarly, the Definition
	39	does not provide a mechanism for namespace control at the module
	40	level, making it impossible to deliver packaged libraries and have a
	41	hope of users using them without name clashes. The ML Basis system
	42	addresses this problem. We have also provided a formal specification
	43	of the ML Basis system at the level of the Definition.
	44
	45	== Also see ==
	46
	47	* http://www.mlton.org/pipermail/mlton/2004-August/016165.html
	48	* http://www.mlton.org/pipermail/mlton-user/2004-December/000320.html