sml-implementers

RE: [Sml-implementers] Subject: Standard ML

[Robert H. <Rob...@cs...>]

No language, natural or artificial, can remain static, if it is used at all;
it will evolve whether we like it or not.  The question is how we manage
that evolution.

There are at least six serious implementations of Standard ML, representing
a substantial commitment by a substantial community to its continuing
vitality.  At present these implementations different in important ways,
particularly in the treatment of separate compilation and in libraries, but
also in correcting deficiencies and making extensions to the language.  It
is vital that we harmonize them.  It is also vital that we, as a community,
discuss possible paths of evolution to keep pace with the world around us.

The community has a choice.  We can either go our separate ways, dissipating
our efforts, and bring a rapid end to there being any community at all.  Or
we can decide that it is in our best interest to work together to guide the
ongoing and inevitable evolution of Standard ML through a community process
that preserves the existence of a common language, preserves the community
that has arisen around it, and nurtures a set of ideas that have inspired
and substantially engaged us all.

It is not for me, nor any one person, to decide, but for us all collectively
to determine whether we will go forward separately or together.  For my
part, I can see no profit in attempting to suppress the process, but
enormous gain in fostering and guiding it.

Bob Harper

-----Original Message-----
From: Robin Milner [mailto:Rob...@cl...]
Sent: Tuesday, September 25, 2001 8:22 AM
To: sml...@li...
Cc: Rob...@cl...
Subject: [Sml-implementers] Subject: Standard ML



We are authors of Standard ML, both 1990 and 1997; we also wrote
the Commentary.   

We welcome standardisation of matters not covered by the 
Definition of Standard ML, such as libraries and separate compilation.

We also welcome language designs built on Standard ML; they may 
proclaim membership of the ML family, as for example CAML does.

However, we will not accept further revision of Standard ML.  It 
is natural that people discuss changes and new features, and thus
that successors of the language will arise.  We expect, however,
the designers of any successor language to make it clear that
their language is not Standard ML. 
 
With regards
Robin Milner, Mads Tofte


_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers

RE: [Sml-implementers] Subject: Standard ML

[David M. <Dav...@pr...>]

I have to say I fundamentally disagree with this analysis.  If have
understood Bob's argument correctly, it is that languages must change to
be viable, that there is pressure within the Standard ML community for
change and that by responding positively to this pressure it is possible
to "manage" it and retain cohesiveness within the Standard ML community.
I believe that all these are false.

First,  is there any reason to believe that programming languages must
change?  Certainly languages must respond to their environment to the
extent of adding new libraries and modules.  I think everyone accepts
that.  Where there is disagreement is whether it is necessary to change
the fundamentals, the elements with which the Definition is concerned.
If one looks at other widely used and certainly viable languages such as
C I cannot see any evidence that they are changing in that area.

Second, is there any pressure for change?  Ken Friis Larsen pointed out
that even among the implementers responding to these messages there
seemed to be a majority against change.  If Standard ML is to be treated
as a serious language the most important community is that of the users
of the language.  I get no impression that they are calling out for
changes, rather the opposite.  A quick look at the Isabelle theorem
prover suggests that it contains around 200 000 lines of Standard ML.  I
am sure Larry and his colleagues would object to having to change this
to accommodate another change in the language definition.  The effect is
that even if the definition of the language changed Poly/ML would have
to continue to support SML97 for the foreseeable future.

Finally, is it possible to manage the diversity?  There is a fundamental
difference of approach between implementers when it comes to the
language.  Some see the Definition as a guideline to be followed as far
as possible but where they perceive deficiencies or where they wish to
make extensions they are happy to diverge from it.  Others, and I would
count myself among them, see the Definition as a form of contract with
the users and attempt to follow it as closely as possible.  I don't see
it is possible to "manage" this difference in philosophy.  Some
implementers will wish to experiment with new language features beyond
any new Definition while others will feel that it is more important to
continue to support the older versions of the language.  Far from
creating harmony between the implementations I can see further change in
the Definition as leading to even greater divergence.

This disagreement is not about the ends but about the means of achieving
them.  I am sure we all want to see Standard ML and languages like it
used more extensively.  It may be that the Standard ML community will
split into those who are interested in language design and in
experimenting with new features and those whose interests lie more in
providing a broader support for the existing language.  Maybe it is too
much to expect a single group to follow both paths.  

David.

On Wednesday, September 26, 2001 3:26 AM, Robert Harper
[SMTP:Rob...@cs...] wrote:
> No language, natural or artificial, can remain static, if it is used
at all;
> it will evolve whether we like it or not.  The question is how we
manage
> that evolution.
> 
> There are at least six serious implementations of Standard ML,
representing
> a substantial commitment by a substantial community to its continuing
> vitality.  At present these implementations different in important
ways,
> particularly in the treatment of separate compilation and in
libraries, but
> also in correcting deficiencies and making extensions to the language.
It
> is vital that we harmonize them.  It is also vital that we, as a
community,
> discuss possible paths of evolution to keep pace with the world around
us.
> 
> The community has a choice.  We can either go our separate ways,
dissipating
> our efforts, and bring a rapid end to there being any community at
all.  Or
> we can decide that it is in our best interest to work together to
guide the
> ongoing and inevitable evolution of Standard ML through a community
process
> that preserves the existence of a common language, preserves the
community
> that has arisen around it, and nurtures a set of ideas that have
inspired
> and substantially engaged us all.
> 
> It is not for me, nor any one person, to decide, but for us all
collectively
> to determine whether we will go forward separately or together.  For
my
> part, I can see no profit in attempting to suppress the process, but
> enormous gain in fostering and guiding it.
> 
> Bob Harper
> 
> -----Original Message-----
> From: Robin Milner [mailto:Rob...@cl...]
> Sent: Tuesday, September 25, 2001 8:22 AM
> To: sml...@li...
> Cc: Rob...@cl...
> Subject: [Sml-implementers] Subject: Standard ML
> 
> 
> 
> We are authors of Standard ML, both 1990 and 1997; we also wrote
> the Commentary.   
> 
> We welcome standardisation of matters not covered by the 
> Definition of Standard ML, such as libraries and separate compilation.
> 
> We also welcome language designs built on Standard ML; they may 
> proclaim membership of the ML family, as for example CAML does.
> 
> However, we will not accept further revision of Standard ML.  It 
> is natural that people discuss changes and new features, and thus
> that successors of the language will arise.  We expect, however,
> the designers of any successor language to make it clear that
> their language is not Standard ML. 
>  
> With regards
> Robin Milner, Mads Tofte
> 
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers

Re: [Sml-implementers] Subject: Standard ML

[Matthias B. <bl...@re...>]

David Matthews wrote:
> 
> First,  is there any reason to believe that programming languages must
> change?  Certainly languages must respond to their environment to the
> extent of adding new libraries and modules.  I think everyone accepts
> that.  Where there is disagreement is whether it is necessary to change
> the fundamentals, the elements with which the Definition is concerned.
> If one looks at other widely used and certainly viable languages such as
> C I cannot see any evidence that they are changing in that area.

C is a very fine example in support of Bob's analysis.  Witness K&R C, ANSI
C, C++ (arguably a "different" language altogether) and now C'99.

> Second, is there any pressure for change?  Ken Friis Larsen pointed out
> that even among the implementers responding to these messages there
> seemed to be a majority against change.

Making such claims (about "majority" and such) would require taking a vote.
Plus, you might even be right: Many of those disappointed with the current
state of the language have already left us for the greener pastures of
OCaml etc.  Of course, we can let this continue to happen (and it will if 
SML proves unable to adapt to its users' needs).  Ultimately this will lead to
SML's death.  (Arguable, it is very sick already.)

> If Standard ML is to be treated
> as a serious language the most important community is that of the users
> of the language.  I get no impression that they are calling out for
> changes, rather the opposite.  A quick look at the Isabelle theorem
> prover suggests that it contains around 200 000 lines of Standard ML.  I
> am sure Larry and his colleagues would object to having to change this
> to accommodate another change in the language definition.  The effect is
> that even if the definition of the language changed Poly/ML would have
> to continue to support SML97 for the foreseeable future.

Bob was quite explicit with the goals of the immediate endeavor: Moderate changes
that clarify what hasn't been clarified so far and minor changes that are hopefully
even backward-compatible.  And if there end up being one or two minor incompatibilities,
so be it: Even a 200,000 lines ML program can be brought up to speed
very quickly.

> Finally, is it possible to manage the diversity?  There is a fundamental
> difference of approach between implementers when it comes to the
> language.  Some see the Definition as a guideline to be followed as far
> as possible but where they perceive deficiencies or where they wish to
> make extensions they are happy to diverge from it.

I would want to make one thing clear here:  This is not something driven by
implementers; this is driven by _users_ of the language (of which implementers
are a part).  Most of the changes that I would like to see are those for
which I find the current workarounds to be too bothersome when _programming_
in ML.

>  Others, and I would
> count myself among them, see the Definition as a form of contract with
> the users and attempt to follow it as closely as possible.

I see it the same way.  But when following the existing contract is no longer
desirable, then one can try to revise it.  This requires some form of
agreement among the parties, and that's what we are trying to get.  We are
not talking about some Holy Scripture here, ML is not a religion (despite the
many religious wars that are being fought over programming languages).

>  I don't see
> it is possible to "manage" this difference in philosophy.  Some
> implementers will wish to experiment with new language features beyond
> any new Definition while others will feel that it is more important to
> continue to support the older versions of the language.

Bob was quite explicit about that, too.  The changes we are talking about (in the
framework of revising Standard ML) are not of the "language research and experiments"
nature.  For the latter (something that researchers will always be interested in),
a standardized language is, indeed, not a good vehicle.  But that's not the issue
here.

> Far from
> creating harmony between the implementations I can see further change in
> the Definition as leading to even greater divergence.

Well, not having further changes will certainly create perfect harmony:
All users and all implementers will agree perfectly (since there will be none).
Unfortunately, it will be the harmony one usually experiences only in graveyards...

(Sorry for sounding so depressed, but this discussion _is_ depressing!)

Matthias

Re: [Sml-implementers] Subject: Standard ML

[John H. R. <jh...@re...>]

In message <715...@ap...>, David Matt
hews writes:
>
...
> 
> First,  is there any reason to believe that programming languages must
> change?  Certainly languages must respond to their environment to the
> extent of adding new libraries and modules.  I think everyone accepts
> that.  Where there is disagreement is whether it is necessary to change
> the fundamentals, the elements with which the Definition is concerned.
> If one looks at other widely used and certainly viable languages such as
> C I cannot see any evidence that they are changing in that area.

C is a poor choice of example.  A substantial revision of the specification
of C (called C99) was just completed a year or so ago.  In fact, I doubt
that you can name any language in widespread use that hasn't had periodic
revision.

Implementations are going to experiment with extensions.  SML/NJ for example,
has lazyness, or patterns, vector patterns and expressions, and soon
functional record update.  These are all features that aid in programming
and should be considered for standardization across implementations.
I would hope that we can continue to call this evolving specification
"Standard ML."

	- John

Re: [Sml-implementers] Subject: Standard ML

[Dave M. <db...@cs...>]

As one who has invested a lot of effort in Standard ML, I agree
wholeheartedly with Bob's reply to Robin and Mads.  A living language will
evolve -- only dead languages remain fixed.

I should point out that the adjective "Standard" turned out to be an
unfortunate choice.  It represented a hope that has clearly not been
bourne out by later developments in the ML community, which is now
regretably divided into two camps.  Perhaps we should let Robin and
Mads keep "Standard", and choose a better adjective to reflect a
renewal of purpose.

While evolution, and hopefully growth, must happen, I agree that we
must go forward together, which requires careful discussion and open
minds, followed up with joint effort.  The current dialogs on
sml-implementers are a good start.

We must at least avoid further fragmentation of the ???? ML camp if we
are going to have a chance of practical success.

Dave MacQueen


> From:  Robert Harper <Rob...@cs...>
> To:    sml...@li...
> Cc:    Rob...@cl...
> Date:  Tue, 25 Sep 2001 22:26:28 EDT
> Subject: RE: [Sml-implementers] Subject: Standard ML

> No language, natural or artificial, can remain static, if it is used at all;
> it will evolve whether we like it or not.  The question is how we manage
> that evolution.
> 
> There are at least six serious implementations of Standard ML, representing
> a substantial commitment by a substantial community to its continuing
> vitality.  At present these implementations different in important ways,
> particularly in the treatment of separate compilation and in libraries, but
> also in correcting deficiencies and making extensions to the language.  It
> is vital that we harmonize them.  It is also vital that we, as a community,
> discuss possible paths of evolution to keep pace with the world around us.
> 
> The community has a choice.  We can either go our separate ways, dissipating
> our efforts, and bring a rapid end to there being any community at all.  Or
> we can decide that it is in our best interest to work together to guide the
> ongoing and inevitable evolution of Standard ML through a community process
> that preserves the existence of a common language, preserves the community
> that has arisen around it, and nurtures a set of ideas that have inspired
> and substantially engaged us all.
> 
> It is not for me, nor any one person, to decide, but for us all collectively
> to determine whether we will go forward separately or together.  For my
> part, I can see no profit in attempting to suppress the process, but
> enormous gain in fostering and guiding it.
> 
> Bob Harper
> 
> -----Original Message-----
> From: Robin Milner [mailto:Rob...@cl...]
> Sent: Tuesday, September 25, 2001 8:22 AM
> To: sml...@li...
> Cc: Rob...@cl...
> Subject: [Sml-implementers] Subject: Standard ML
> 
> 
> 
> We are authors of Standard ML, both 1990 and 1997; we also wrote
> the Commentary.   
> 
> We welcome standardisation of matters not covered by the 
> Definition of Standard ML, such as libraries and separate compilation.
> 
> We also welcome language designs built on Standard ML; they may 
> proclaim membership of the ML family, as for example CAML does.
> 
> However, we will not accept further revision of Standard ML.  It 
> is natural that people discuss changes and new features, and thus
> that successors of the language will arise.  We expect, however,
> the designers of any successor language to make it clear that
> their language is not Standard ML. 
>  
> With regards
> Robin Milner, Mads Tofte
> 
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers

RE: [Sml-implementers] Subject: Standard ML

[Andrew K. <ak...@mi...>]

Matthias Blume wrote:

> Well, not having further changes will certainly create=20
> perfect harmony: All users and all implementers will agree=20
> perfectly (since there will be none). Unfortunately, it will=20
> be the harmony one usually experiences only in graveyards...
>=20
> (Sorry for sounding so depressed, but this discussion _is_=20
> depressing!)

Then let me try and bring some cheer to the discussion. This
is the first time I can remember a significant number of SML
implementers discussing the language in such detail at all.
Some points:

SML is not yet dead
-------------------
There are a surprising number of live implementations or=20
nearly-ready implementations of the language:

(In no particular order)
Moscow ML, SML/NJ, TILT, Church Project, MLton, Poly-ML,=20
MLj, SML.NET

I'd really like to see the "nearly-ready" implementations=20
released (and here I include the "real soon now" version 111=20
of SML/NJ). Such a breadth of implementations each with its=20
own focus is surely a sign of life in a language.

Our proposals are modest
------------------------
Almost all of the proposals so far discussed come under=20
one of the headings=20

  (A) "matters not covered by the Definition of Standard ML",=20
  (B) "mistakes in the Definition" or=20
  (C) "changes to SML that don't break existing code".=20

Here's a quick categorization:

  (A) Libraries, compilation management, FFI, the "top level",
      scope of flex-record/overloading resolution
  (B) Free type variables at top level
  (C) Structure sharing, vector expressions/patterns, or-patterns,
      higher-order functors, non-expansive raise, laziness,
      withtype in signatures, updateable records, polymorphic
      recursion

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
     =20
Unless one is really hard-line (implementations must be=20
bug-for-bug compatible with the Definition) it's hard to argue
with (A) and (B). The danger with (C) is that each implementation
has its own ad-hoc extensions; then programmers write code that uses
the extensions and is therefore tied to a single implementation.
How about adopting the following procedures:

(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?)

(2) Ideally extensions should be specified in the style of the=20
Definition, thus providing a solid reference for compiler writers.

(3) Compilers should have a compatibility mode in which extensions=20
are rejected or deprecated. This could be controllable at the level=20
of individual extensions.

(4) Where possible we should provide source-to-source translation tools=20
that rewrite extensions as SML'97 code. A common parsing and=20
layout-preserving pretty-printing infrastructure would be very helpful
here, but with it I believe that some of the proposed extensions can
be translated away (e.g. or-patterns, vector syntax, updateable
records).

Comments?
- Andrew.

RE: [Sml-implementers] Subject: Standard ML

[Peter S. <se...@di...>]

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

RE: [Sml-implementers] Subject: Standard ML

[Andrew K. <ak...@mi...>]

I wrote:

> There are a surprising number of live implementations or=20
> nearly-ready implementations of the language:
>=20
> (In no particular order)
> Moscow ML, SML/NJ, TILT, Church Project, MLton, Poly-ML,=20
> MLj, SML.NET

Of course, I forgot to add: the ML Kit. Any more to take the
count to ten?
- Andrew.

Re: [Sml-implementers] Subject: Standard ML

[Ken F. L. <kf...@it...>]

> Of course, I forgot to add: the ML Kit. Any more to take the
> count to ten?

Well there is HaMLet:
        http://www.ps.uni-sb.de/hamlet/
And if that doesn't count, how about:
        http://www.ps.uni-sb.de/alice/

(Even though it clearly denotes itself as a language different from SML).


--Ken 

Re: [Sml-implementers] Subject: Standard ML

[Andreas R. <ros...@ps...>]

Ken Friis Larsen wrote:
>=20
> Well there is HaMLet:
>         http://www.ps.uni-sb.de/hamlet/
> And if that doesn't count, how about:
>         http://www.ps.uni-sb.de/alice/
>=20
> (Even though it clearly denotes itself as a language different from SML=
).

Some short comments:

Alice is a system for distributed and concurrent constraint programming
currently being developed here in Saarbr=FCcken, and will hopefully be
ready some time next year. Although showing some quite fundamental
differences, it still aims to be a mostly conservative extension of SML.

HaMLet is my personal SML toy interpreter that evolved as a byproduct of
the Alice project. It is by now a fairly complete implementation and I
will release it next week, after filling some remaining holes.

As part of the HaMLet documentation I tried to compile a list of all
known mistakes and `grey areas' in the revised Definition (based on what
Kahrs did for SML'90). If people are interested, I could turn it into a
stand-alone document. It might be useful in the discussion about fixes.

	- Andreas

RE: [Sml-implementers] Subject: Standard ML

[Robert H. <Rob...@cs...>]

Thanks, Andrew.  This is a nice summary of how I think we ought to proceed.
I agree that changes in category (D) are more delicate, and we should
certainly take pains to ensure that legacy code is not simply thrown
overboard.

Bob

-----Original Message-----
From: Andrew Kennedy [mailto:ak...@mi...]
Sent: Thursday, September 27, 2001 10:21 AM
To: Matthias Blume; sml...@li...
Subject: RE: [Sml-implementers] Subject: Standard ML


Matthias Blume wrote:

> Well, not having further changes will certainly create 
> perfect harmony: All users and all implementers will agree 
> perfectly (since there will be none). Unfortunately, it will 
> be the harmony one usually experiences only in graveyards...
> 
> (Sorry for sounding so depressed, but this discussion _is_ 
> depressing!)

Then let me try and bring some cheer to the discussion. This
is the first time I can remember a significant number of SML
implementers discussing the language in such detail at all.
Some points:

SML is not yet dead
-------------------
There are a surprising number of live implementations or 
nearly-ready implementations of the language:

(In no particular order)
Moscow ML, SML/NJ, TILT, Church Project, MLton, Poly-ML, 
MLj, SML.NET

I'd really like to see the "nearly-ready" implementations 
released (and here I include the "real soon now" version 111 
of SML/NJ). Such a breadth of implementations each with its 
own focus is surely a sign of life in a language.

Our proposals are modest
------------------------
Almost all of the proposals so far discussed come under 
one of the headings 

  (A) "matters not covered by the Definition of Standard ML", 
  (B) "mistakes in the Definition" or 
  (C) "changes to SML that don't break existing code". 

Here's a quick categorization:

  (A) Libraries, compilation management, FFI, the "top level",
      scope of flex-record/overloading resolution
  (B) Free type variables at top level
  (C) Structure sharing, vector expressions/patterns, or-patterns,
      higher-order functors, non-expansive raise, laziness,
      withtype in signatures, updateable records, polymorphic
      recursion

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
      
Unless one is really hard-line (implementations must be 
bug-for-bug compatible with the Definition) it's hard to argue
with (A) and (B). The danger with (C) is that each implementation
has its own ad-hoc extensions; then programmers write code that uses
the extensions and is therefore tied to a single implementation.
How about adopting the following procedures:

(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?)

(2) Ideally extensions should be specified in the style of the 
Definition, thus providing a solid reference for compiler writers.

(3) Compilers should have a compatibility mode in which extensions 
are rejected or deprecated. This could be controllable at the level 
of individual extensions.

(4) Where possible we should provide source-to-source translation tools 
that rewrite extensions as SML'97 code. A common parsing and 
layout-preserving pretty-printing infrastructure would be very helpful
here, but with it I believe that some of the proposed extensions can
be translated away (e.g. or-patterns, vector syntax, updateable
records).

Comments?
- Andrew.

_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers

RE: [Sml-implementers] Subject: Standard ML

[Robert H. <Rob...@cs...>]

Please do consolidate your concerns about The Definition.  Then we can =
all
compare notes, because I think others have similar concerns (some =
already
raised here).

Bob Harper

-----Original Message-----
From: Andreas Rossberg [mailto:ros...@ps...]
Sent: Friday, September 28, 2001 4:31 AM
To: sml...@li...
Cc: Ken Friis Larsen; Andrew Kennedy
Subject: Re: [Sml-implementers] Subject: Standard ML


Ken Friis Larsen wrote:
>=20
> Well there is HaMLet:
>         http://www.ps.uni-sb.de/hamlet/
> And if that doesn't count, how about:
>         http://www.ps.uni-sb.de/alice/
>=20
> (Even though it clearly denotes itself as a language different from =
SML).

Some short comments:

Alice is a system for distributed and concurrent constraint programming
currently being developed here in Saarbr=FCcken, and will hopefully be
ready some time next year. Although showing some quite fundamental
differences, it still aims to be a mostly conservative extension of =
SML.

HaMLet is my personal SML toy interpreter that evolved as a byproduct =
of
the Alice project. It is by now a fairly complete implementation and I
will release it next week, after filling some remaining holes.

As part of the HaMLet documentation I tried to compile a list of all
known mistakes and `grey areas' in the revised Definition (based on =
what
Kahrs did for SML'90). If people are interested, I could turn it into a
stand-alone document. It might be useful in the discussion about fixes.

	- Andreas

_______________________________________________
Sml-implementers mailing list
Sml...@li...
https://lists.sourceforge.net/lists/listinfo/sml-implementers

Re: [Sml-implementers] Subject: Standard ML

[Andreas R. <ros...@ps...>]

Robert Harper wrote:
> 
> Please do consolidate your concerns about The Definition.  Then we can all
> compare notes, because I think others have similar concerns (some already
> raised here).

OK, here you go. Don't be shocked: the list is quite exhaustive and
contains
a lot of pedantic stuff. There are very few "major" issues.

Of course, I welcome comments on anything I have included. The list
already
contains bits from the recent discussions here. If anybody has issues
that are missing I would also like to hear about it.

During compiling this I also made a bunch of contrived test files to
see how implementations cope with some of the more obscure details of
the
Definition (i.e. those that are tedious to implement or are pretty
counter-intuitive, as noted in the list). Here is a table of the results
(I hope Netscape does not gargle it):

		SML/NJ	MosML	MLton	MLKit	Poly/ML	MLWorks	Alice
		110.0.7	2.00	010706	4.0.0	4.1.1	2.0	Oper2

abstype		-	-	+	-	-	-	+
asterisk	-	-	-	-	+	+	+
exhaustive	-	+	+	+	-	+	+
flexrecord	+	+	+	+	+	-	+
fun-case	-	-	-	-	-	-	-
id		-	-	-	+	+	+	+
nonexhaustive	+	+	-	-	+	+	-
open		-	+	-	+	+	-	-
overloading	-	+	+	+	+	-	-
scon		-	+	-	-	+	-	+
semicolon	+	+	-	-	-	+	+
sharing		-	+	+	+	+	+	-
typespec	+	-	-	-	-	+	+
undetermined	-	+	+	-	+	+	+
valrec		-	-	-	(1)	-	-	-
where-and	-	-	+	-	-	-	+
where		-	+	+	+	-	-	-
withtype	-	+	+	+	+	+	+

		(1) Internal error.

You can find the test files attached as well. Although several of
the examples are pretty pathological, the table probably indicates
that some of the features in question may be worth a revision.

	- Andreas

Re: [Sml-implementers] Subject: Standard ML

[Stephen W. <sw...@in...>]

Andreas:
> During compiling this I also made a bunch of contrived test files to
> see how implementations cope with some of the more obscure details of
> the
> Definition (i.e. those that are tedious to implement or are pretty
> counter-intuitive, as noted in the list). Here is a table of the results
> (I hope Netscape does not gargle it):
...

Three of your test cases tickled another obscure part of the
Definition (to me anyway), and I suspect it was unintentional on your
part.  The tests "asterisk", "semicolon", and "typespec" contained the
'\r' character (ascii decimal 13).  Quoting from the Definition:
  
Section 2.5:
	Comments and formatting characters separate items (except with
	string constants; see Section 2.2) and are otherwise ignored.
Section 2.2:
	The formatting characters are a subset of the non-printable
	characters including at least space, tab, newline, formfeed.

Since carriage return is not required to be a formatting character, I
believe that it is acceptable for an implementation to reject programs
containing carriage returns, although it is also allowable to accept
them.  At present, MLton rejects them.

I would be happy for clarification.


BTW, as an implementor, I really appreciate having examples like this
to clarify things.   Thanks for making them.  I think that a set of
well-constructed examples is as essential as the Definition in making
different implementations consistent.  I would like to see more cases
like these, and for all proposed language extensions to come along with
such a set of test cases.

Re: [Sml-implementers] Subject: Standard ML

[Peter S. <se...@di...>]

Andreas,

> OK, here you go. Don't be shocked: the list is quite exhaustive and
> contains a lot of pedantic stuff. There are very few "major" issues.

Thanks for the list.  I believe the scarcity of major issues testifies
to the amount of work and care that has gone into the Definition, and
also reflects much feedback from thoughtful users and implementors.

It would probably take five years to obtain similar quality in a
new-style definition for a new language, and another five-ten years
before implementations agree on the interpretation of the fine
points. 

Reason enough not to destroy what we have.

> During compiling this I also made a bunch of contrived test files to
> see how implementations cope with some of the more obscure details 

This is a very useful idea, and the results comforting ...

But, I don't understand why valrec.sml test case should raise Bind:

    val rec LESS = fn x => x    (* will raise Bind *)
    and NONE as SOME = fn x => x
    val SOME = 1;  

According to rule (26), and as stressed in the comment to that rule,
the identifier status may change in the recursive binding, so LESS,
NONE and SOME are value variables, and the example is no different
from this:

    val rec a = fn x => x    (* will raise Bind *)
    and b as c = fn x => x
    val c = 1;  

Peter
--
Department of Mathematics and Physics  *  http://www.dina.kvl.dk/~sestoft/
Royal Veterinary and Agricultural University          *  Tel +45 3528 2334
Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark  *  Fax +45 3528 2350 

Re: [Sml-implementers] Subject: Standard ML

[Stephen W. <sw...@in...>]

> But, I don't understand why valrec.sml test case should raise Bind:
> 
>     val rec LESS = fn x => x    (* will raise Bind *)
>     and NONE as SOME = fn x => x
>     val SOME = 1;  

Rule (26) has no impact on the dynamic semantics, as defined by rules
(124, 125, 126), which will match the LESS pattern just as in

	val LESS = fn x => x

In both cases,

	E, v |- LESS => FAIL

and hence by rule 125,

	E |- LESS = fn x => x => [Bind]

and hence, by the implicit extension of rule 126 to exception packets,

	E |- rec LESS .... => [Bind]

Re: [Sml-implementers] Subject: Standard ML

[Peter S. <se...@di...>]

> > But, I don't understand why valrec.sml test case should raise Bind:
> > 
> >     val rec LESS = fn x => x    (* will raise Bind *)
> >     and NONE as SOME = fn x => x
> >     val SOME = 1;  
> 
> Rule (26) has no impact on the dynamic semantics [...]

Of course, I see.  So the point is that rule (126) in the dynamic
semantics neglects to change the identifier status, but the behaviour
of the implementations is sensible.

Peter
--
Department of Mathematics and Physics  *  http://www.dina.kvl.dk/~sestoft/
Royal Veterinary and Agricultural University          *  Tel +45 3528 2334
Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark  *  Fax +45 3528 2350 

Re: [Sml-implementers] Subject: Standard ML

[Dave B. <da...@ta...>]

That's good work.

I take it that in your table, '+' indicates a passed test, and '-' a failed
one?

Regarding section 4.10, and the exhaustiveness checking of exception
constructors within functors, I believe that MLWorks does check this when
the functor is applied.  I don't have an implementation at hand to check
this, but perhaps you could add this to your test programs?

Dave.

Re: [Sml-implementers] Subject: Standard ML

[Andreas R. <ros...@ps...>]

Dave Berry wrote:
> 
> I take it that in your table, '+' indicates a passed test, and '-' a failed
> one?

Yes (modulo the corrections necessary due to the \r stuff).

> Regarding section 4.10, and the exhaustiveness checking of exception
> constructors within functors, I believe that MLWorks does check this when
> the functor is applied.  I don't have an implementation at hand to check
> this, but perhaps you could add this to your test programs?

That's interesting. I only have MLWorks running at home so I cannot test
it right now. I will check over the weekend.

	- Andreas

Re: [Sml-implementers] Subject: Standard ML

[Andreas R. <ros...@ps...>]

Dave Berry wrote:
> 
> Regarding section 4.10, and the exhaustiveness checking of exception
> constructors within functors, I believe that MLWorks does check this when
> the functor is applied.  I don't have an implementation at hand to check
> this, but perhaps you could add this to your test programs?

MLWorks indeed does that. I added a test case "redundant". Still, this
is not something the Definition should enforce, IMHO. It requires a form
of abstract interpretation that seems a bit unreasonable weighed with
the benefits, in particular in the presence of separate compilation. No
other system implements it.

	- Andreas

Re: [Sml-implementers] Subject: Standard ML

[Andreas R. <ros...@ps...>]

Stephen Weeks wrote:
> 
> Three of your test cases tickled another obscure part of the
> Definition (to me anyway), and I suspect it was unintentional on your
> part.  The tests "asterisk", "semicolon", and "typespec" contained the
> '\r' character (ascii decimal 13).  Quoting from the Definition:
> 
> Section 2.5:
>         Comments and formatting characters separate items (except with
>         string constants; see Section 2.2) and are otherwise ignored.
> Section 2.2:
>         The formatting characters are a subset of the non-printable
>         characters including at least space, tab, newline, formfeed.

True, I think it is an oversight that \r is not included, since it is
obligatory at least on Dos/Windows-based systems and sources should be
portable across the "major" OS'es. And it would make sense to include at
least those formatting characters for which there is explicit escape
syntax.

> At present, MLton rejects them.

Oops, I didn't notice that this was the problem. After removing the
offending characters, MLton indeed accepts the "semicolon" and
"typespec" examples. The same seems to be true for the MLKit, which
accepts all three examples now.

> BTW, as an implementor, I really appreciate having examples like this
> to clarify things.

Yes, in fact the main reason I made them was for me as an implementor to
get all of this working in HaMLet. I finally managed it for all but two
of the examples (abstype and fun-case) but it was not always fun. Note
btw. that the reason why "abstype" is actually working in Alice is only
due to the fact that the compiler does not distinguish equality types. I
guess the same is true for MLton?

	- Andreas

Re: [Sml-implementers] Subject: Standard ML

[Stephen W. <sw...@in...>]

> True, I think it is an oversight that \r is not included, since it
> is obligatory at least on Dos/Windows-based systems and sources
> should be portable across the "major" OS'es.

Agreed.  I changed MLton to accept \r and \r\n as a newline.

> And it would make sense to include at least those formatting
> characters for which there is explicit escape syntax.

I'm not sure what other implementations do here, for example, on \b,
\v, \f.  I've left them out for now.  Anyways, I think that this point
should be completely nailed down as part of the process of clarifying
the definition.

> Yes, in fact the main reason I made them was for me as an implementor to
> get all of this working in HaMLet. I finally managed it for all but two
> of the examples (abstype and fun-case) but it was not always fun. Note
> btw. that the reason why "abstype" is actually working in Alice is only
> due to the fact that the compiler does not distinguish equality types. I
> guess the same is true for MLton?

Right (among the hundred or so things that MLton ignores).  I will
probably go for the overloading solution if/when I ever get around to
writing a proper front-end.  It doesn't seem too hard.

Anyways, I've fixed bugs so that MLton now behaves correctly on all
your tests except for fun-case (I have no idea how to get that) and
nonexhaustive (warnings are one of many things MLton doesn't do).
Thanks.

Re: [Sml-implementers] Subject: Standard ML

[Andreas R. <ros...@ps...>]

Stephen Weeks wrote:
> 
> > Note 
> > btw. that the reason why "abstype" is actually working in Alice is only
> > due to the fact that the compiler does not distinguish equality types. I
> > guess the same is true for MLton?
> 
> Right (among the hundred or so things that MLton ignores).  I will
> probably go for the overloading solution if/when I ever get around to
> writing a proper front-end.  It doesn't seem too hard.

It's not easy, I'm afraid. Consider the following abstype declaration:

	abstype t = T with
	    val t = T
	    val eq = op=
	end

Depending on the context, type inference has to choose between two type
schemes it can sensibly assign to eq:

	sigma1 = ''a * ''a -> bool
	sigma2 = t * t -> bool

But both exclude each other. Every program that requires both must be
rejected. Here are some examples covering most interesting cases:

(* (1a) Elaborates with sigma1 *)
abstype t = T with
    val t = T
    val eq = op=
end;
eq(2,3);

(* (1b) Elaborates with sigma2 *)
abstype t = T with
    val t = T
    val eq = op=
end;
eq(t,t);

(* (1c) Reject: elaborates with neither *)
abstype t = T with
    val t = T
    val eq = op=
end;
eq(2,3) andalso eq(t,t);

(* (2a) Elaborates with sigma1 *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t)
end;
eq(2,3);

(* (2b) Elaborates with sigma2 *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t)
end;
eq(t,t);

(* (2c) Reject *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(2,3)
end;
eq(t,t);

(* (3a) Elaborates with sigma1 *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t) andalso eq(2,3)
end;
eq(2,3);

(* (3b) Reject *)
abstype t = T with
    val t = T
    val eq = op=
    val _ = eq(t,t) andalso eq(2,3)
end;
eq(t,t);

In most of these examples, when trying standard type inference, we had
to instantiate eq's type scheme before knowing which it is. In
particular, later declarations may invalidate possible typings for the
abstype body (e.g. 2a vs 2b, or 3a vs 3b). Not really obvious how this
could be implemented. And it is reminiscent of the free tyvar problem,
only worse.

So I believe it is very hard to get the semantics of abstype right in a
compiler - probably even harder than parsing fun-case. IMHO abstype in
its current form is simply broken. That is another reason why I would
like to see it removed from the language -- or turned into a derived
form:

	abstype t = conbind with dec end --->
		local datatype t = conbind in type t = t dec end

AFAICS, the only difference with the current definition would be that
equality of t is transparent - but that is exactly what is required to
avoid the current problems of non-principality and type structures not
respecting equality. And it is a conservative change, not breaking any
legal program (I think).

	- Andreas

Re: [Sml-implementers] Subject: Standard ML

[Stephen W. <sw...@in...>]

> It's not easy, I'm afraid. Consider the following abstype declaration:
> 
> 	abstype t = T with
> 	    val t = T
> 	    val eq = op=
> 	end
> 
> Depending on the context, type inference has to choose between two type
> schemes it can sensibly assign to eq:
> 
> 	sigma1 = ''a * ''a -> bool
> 	sigma2 = t * t -> bool
...

Thanks for all the examples.  They didn't quite convince me that it
would be too hard to implement, since it seems like similar tricks
that one uses to implement overloading would work in them (namely,
delaying a decision about the type of an instantiation until all the
uses are known).  However, the following example does convince me
that this is hard to implement.

(* Elaborates with sigma1 *)
abstype t = T with
   val t = T
   val eq = op=
end
fun f (x, y) = eq (x, y)
val _ = f (1, 2)

(* Reject *)
abstype t = T with
   val t = T
   val eq = op=
end
fun f (x, y) = eq (x, y)
val _ = f (1, 2)
val _ = eq (t, t)

These two examples show that one actually has to make decisions about
generalization before all of the uses are known.  This is worse than
overloading, which only instantiates to monotypes, not type variables.

> So I believe it is very hard to get the semantics of abstype right in a
> compiler - probably even harder than parsing fun-case. IMHO abstype in
> its current form is simply broken. That is another reason why I would
> like to see it removed from the language -- or turned into a derived
> form:
> 
> 	abstype t = conbind with dec end --->
> 		local datatype t = conbind in type t = t dec end
> 
> AFAICS, the only difference with the current definition would be that
> equality of t is transparent - but that is exactly what is required to
> avoid the current problems of non-principality and type structures not
> respecting equality. And it is a conservative change, not breaking any
> legal program (I think).

I agree, and like your solution.

Re: [Sml-implementers] Subject: Standard ML

[Dave B. <da...@ta...>]

At 18:51 08/10/2001, Andreas Rossberg wrote:
> IMHO abstype in
>its current form is simply broken. That is another reason why I would
>like to see it removed from the language -- or turned into a derived
>form:
>
>	abstype t = conbind with dec end --->
>		local datatype t = conbind in type t = t dec end
>
>AFAICS, the only difference with the current definition would be that
>equality of t is transparent - but that is exactly what is required to
>avoid the current problems of non-principality and type structures not
>respecting equality. And it is a conservative change, not breaking any
>legal program (I think).

It doesn't break any legal program, but it could break a library, and also
render books obsolete.  One use (arguably the only remaining use) of
abstype in the full language is precisely to remove the equality attribute
of a type.  If a library author has made use of this property, then removal
of the property would make that implementation unsound (even though it
would still compile).

IMO it would be preferable to settle on the existing behaviour of most
compilers.  Ideally we should replace the rule in the Definition with one
that doesn't have this flaw, but if that isn't possible then we should just
document this as a problem in the Definition and explain how compilers
should behave in practice.

I don't know if a formal specification is practical.  One approach might be
to reintroduce the notion of principal environments purely for the body of
abstypes.  But that might be too restrictive (and it could possibly break
existing code). 

Dave.