sml-implementers — Standard ML implementers

Re: [Sml-implementers] compilation management

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

At 10:10 21/09/2001, Matthias Blume wrote:
>> We could even go so far as to require that no files
>> in a given library should be case-insensitive-equal. ...
>
>This I wouldn't do -- not as a requirement that we burn into a language
>spec.  The main reason for my saying this is that we should not have to care
>about such OS- and filesys-specifics at all.

One thing to consider is whether to provide any support for directories in
the file paths.  If so, then either we need a convention for directory
syntax, or people may have to rewrite their project files when they move
between OSs.  (Although I believe Windows now recognises Unix-style
directory syntax -- i.e forward slash).  If we do adopt such a convention,
then we are already part way to limiting the names that can appear.

>Otherwise there will be no end
>to it:

That depends; portability isn't all or nothing.  As a concrete proposal,
suppose that files had to use the following character set:
[a-zA-Z0-9_+.-], they had to be case-insensitive, and directories were
indicated with forward slashes.  This would be portable across all versions
of Windows (including CE, and including both FAT and NTFS), all versions of
Unix/Linux, and (I think) MacOS.  Projects might not port to OS's that
limit the length of file names beyond the user's choice of names, or OS's
that have other limitations; in these cases users would have to rewrite the
file names.  So this achieves a level of portability that is pragmatically
useful, and is never worse than the alternative.

Possibly the most annoying effect of this limitation would be on people who
want to write filenames in an non-English language.  But they already have
to write all their identifiers in ASCII.

I'm not strongly wedded to this argument, I just think it's worth considering.

Dave.

[Sml-implementers] Standard ML

[Robin M. <Rob...@cl...>]

Dear sml-implementers

Since my last message to the implementers list, I've seen contributions
by Mads Tofte, Dave Berry and Bob Harper.  I would like to comment on these.
Before doing so, let me say again that I greatly value the development of
ML.  The fact that we disagree over the way to do it doesn't diminish the
importance of doing it. 
 
Mads says "I think it reasonable that the onus is on those who want change".
I fully agree with this, and below I try to say what I think this means.

I go along with a lot of what Dave Berry says in his careful message. 
I won't comment in detail, but hang my response on one of his paragraphs:

	So can we find a common ground in which we can evolve "Standard ML" 
	without risking the problems that you warn of?  (Assuming that the 
	implementers can reach agreement between ourselves, of course, which 
	is yet to be proven). I think we can: the key is to minimise the 
	risks to stability, to manage expectations, and to clearly delineate 
	authorship.

It's here that I disgree.  Instead of "I think we can" I would say "I
shall not believe so until I see it".  That is not to criticise any of
those aiming to do it; but it does firmly say that the onus is on
those who want change.  I have seen nothing to suggest that those who
want change agree on what they want (even when they _seek_ to agree);
in the development of the Definition --which by the way was coordinated
with implementers-- we often found that seemingly small differences
over seemingly small matters grew quite unexpectedly, and consumed a
great deal of effort.  The only evidence of consensus will be the delivery
of what Dave calls a de facto revision of Standard ML, completed and tied in
well with the existing Definition.  Those embarking on this exercise,
which I think is a worthy one, must therefore call it something
different from Standard ML; when they have completed it, the rest of
the community is free to accept it or not.

I thank Bob Harper for his tribute to my past efforts.  It's a good
time for me also to thank all those who took part in defining,
implementing and promulgating SML, and made it work so well in spite
of their differences.

I would like to take up a few things in Bob's message.  He says

 	 ... we are committed to the existence of a language given by a 
	formal definition (........ )  This does not mean, however, that 
	the language is nothing more than its formal definition. ....

I'm not aware that anyone has put forward the latter strange view, so it's
irrelevant and confusing to mention it.  He also says

	To pretend that any modification to Standard ML creates a new 
	and independent language flies in the face of reality.

No-one pretends this, at least I don't.  Languages evolve into each other.
He says:

	Moreover, as Robin aptly points out, the revision of the definition 
	in 1997 increased his (and my) confidence in it, not the other 
	way around.

In fact, in my message I explicitly asserted the other way around.  I said 
"The result wasn't perfect; I trust the '97 Definition more in some respects, 
but less in other respects, than the '90 semantics."   Finally he asserts

	Evolving the definition is no more difficult than evolving an
	implementation. 

Of course one can evolve a definition by simply deciding to change a few
things, but this is clearly not what any of us would mean by evolving a 
definition.  We would mean something much more careful, including coordinating
it with implementations, checking self-consistency when changes permeate
the semantics, and even ensuring that theorems which were proved (sometimes 
by semi-automatic proof systems) of the old definition remained true of the 
new.   I'm not aware that this kind of comprehensive evolution of a fully 
formal definition of an industrial-strength language has ever been done; 
as I said in my message, I believe it's an open problem how to define 
languages in a way that supports change.  

To summarise: I haven't changed my view.  I think it very reasonable
that a group of people including implementers should put forward a
proposed modification to Standard ML, under another name.  The more
who agree to take part the greater the likelihood of divergence, but
the stronger the consensus when achieved.  The community at large can
then assess what has been done.  I remain resolutely opposed to
carrying out this exercise under the name Standard ML; I trust that
using another name won't deter those who want to do the work for 
scientific reasons.

I have held this view for a long time, and already taken too much space 
expressing it, so I probably won't send another message; but I hope
the people on this list will take my view seriously into account.

With regards 
Robin Milner

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] compilation management

[David S. <sw...@cs...>]

Here is our description of TILT's compilation management system.
Comments and suggestions are appreciated.

David Swasey and Tom Murphy

On Wed, 19 Sep 2001 17:27:38 EDT, Robert Harper wrote:
> We will send a brief summary of our compilation mechanism to this list
> shortly.

RE: [Sml-implementers] maintaining a language (definition)

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

Hello everyone:

Sorry for the long delay in replying, it has been a very busy week for me.
As it turns out, Dave Berry and Dave MacQueen have largely expressed my
views on the matter, and have probably done so better than I could have.

A few salient points emerge in my mind:

1. Standard ML belongs to the community of those who have devoted so much to
it.  I hadn't realized until our recent discussion just how many different
implementations there are out there!  Languages are like children: you bring
them up and then they exist on their own.  We are all very deeply in Robin's
debt for having conceived ML and presided over its maturation, but it is, by
now, a full-fledged adult with its own life.

2. As I've previously articulated in an earlier organizational message, it
is a clear principle of the community that we are committed to the existence
of a language given by a formal definition (as opposed to the more common
approach of defining a language by the one "blessed" implementation of it).
This does not mean, however, that the the language is nothing more than its
formal definition.  Rather it is the means by which we, as a community,
understand each other and communicate our shared intentions.

3. It is important that we as a community manage the inevitable and ongoing
evolution of Standard ML.  To pretend that any modification to Standard ML
creates a new and independent language flies in the face of reality.

4. Evolving the definition is no more difficult than evolving an
implementation.  Indeed, the definition started life as an implementation of
ML modules; the semantic objects are a formalization of the data structures
used to implement it back in 1985!  Moreover, as Robin aptly points out, the
revision of the definition in 1997 increased his (and my) confidence in it,
not the other way around.  Nevertheless implementation and application
experience raises technical questions about the definition and suggests
modifications and extensions that we could not "think up" in the absence of
that experience.

Now, let's please get on with our technical discussions!  I believe that the
two topics currently on the table are to design a separate compilation
mechanism and to resolve outstanding issues with the interaction between
sharing specifications and type definitions in signatures.

Bob Harper

[Sml-implementers] maintaining a language (definition)

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

I think there is a fallacy implicit in Robin's response that should be
pointed out.  Robin's idea seems to be that you write a formal
definition (more or less isolated from implementer and user input),
publish it, and that is it.  In reality, a language definition
(including core library specs) needs to be maintained over time just
as much as an implementation, but in a different style, in
adherence to somewhat different rules and constraints.

Definition maintenance should include:

1) correcting errors, both superficial and substative

2) clarifications, resolution of ambiguities

3) adoption of improved definition techniques (some of which would be
incremental and local, some of which may require extensive or global
changes)

4) correction of misdesigned language features (e.g. nonsensical "val
rec rec rec ..." syntax)

5) incremental addition of new language features (e.g OR patterns,
functional record concatenation, structure "where" definitions,
lazy datatypes)

6) specification of new libraries

The maintenance of the Definition should be carried out by a trusted
core group with mechanisms for open publication and community
discussion of proposed changes, including particularly involvement of
the implementation community.  The rate of change should be limited
and managed according to a plan to allow for the implementation and
user communities to adapt, perhaps following an episodic change policy
(e.g. a new "release" of a major component of the definition every 4
or 5 years).

The Definition should be an "open" document, with community control
over how changes get committed.  As with open source software, there
can be stable and developmental versions.  The definition sources
should probably be maintained in a public CVS repository, for instance
in the Standard ML sourceforge project.

One of my regrets about the Definition is that it is frozen in
a published book, and "owned" by it's original authors and the
publisher.  It should belong to the community, and I personally
am willing to transfer my share to the community.  We should look
into the feasibility of opening access to the definition in some
form (presumably the latex sources).  This should be possible since
I don't think either the authors or the publisher have a significant
economic incentive to keep it closed at this point.  This argument
also applies to the Basis specification as well, which has to be
regarded as an integral and essential part of the Definition.

As Robin pointed out, maintaining a definition is a nontrivial task,
but I am not convinced that it a significanly larger and more
difficult task than maintaining an implementation.  In some ways
it is certainly easier, because there are fewer levels of abstraction
to be concerned about, and it does not have to adapt to evolving
platform technologies.

Dave MacQueen

Re: [Sml-implementers] Subject: Standard ML

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

> From:  "Stefan Monnier" <monnier+lists.smlnj.users/news/@RUM.cs.yale.edu>
> To:    sm...@re...
> Date:  04 Oct 2001 19:30:35 EDT
> Subject: Re: [Sml-implementers] Subject: Standard ML

> >>>>> "Matthias" == Matthias Blume <bl...@re...> writes:
> > Well, that settles that.  Sounds like "Standard ML" is soon to be officiall
> y
> > dead.  Ideas for a new name, anyone?
> 
> SuperML ?
> 
> 	Stefan

"Standard" was a poor choice of adjectives in the first place, so I
for one would be glad to discard it.

However, it would be convenient to keep the "SML" acronym.
Stefan's suggestion satisfies that criterion.  Other choices might
be "Superior", "Select", "Simple", "Saxon-Anglo(?)", ... 
Any others?

Or we might go to NML -- Nonstandard ML, New ML, ...

Or, since no one has a trademark on it as far as I know, why
not simply ML?  I've noticed that here in Caml Land, people often
contrast Caml and "ML".

Dave 

Re: [Sml-implementers] extensions to SML

[Martin E. <ma...@di...>]

Hi there,

Matthias Blume <bl...@re...> writes:

> Ken Friis Larsen wrote, replying to Bob Harper:
>
> > But we don't want to repeat the fiasco of the Standard Basis Library
> > (for those involved, apologies for being so blunt).
> 
> What exactly is the "fiasco"?  (I like the SBL a lot, and I am not one of 
> its designers.)

Ken, I agree with Matthias Blume on this issue; the Standard Basis
Library is definitely a success, partly because all Standard ML
implementations support most of the library, but in particular for the
following reasons:

  1. The basis library is very stable; it has not changed since 1997.

  2. The newest specification is published on the web, which makes the
     specification available to all implementers, programmers, book
     writers, and others.

  3. Quite a few programs (also large ones, such as theorem provers
     and compilers) have been developed using the library and the
     library is documented in several text books.

I think we owe much to the editors of the library for not falling into
the trap of continuously suggesting modifications of the
library. Revisions have occured only when absolutely necessary, which
make programs that use the library highly portable over time. With the
stability of the library, the editors have treated all users with deep
respect.

Regards,

Martin Elsman

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...>]

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

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

Robert Harper wrote:
> 
> Thanks!  I can't read your chart because you rely on fixed-width fonts and
> tabbing conventions!  Please expand tabs and re-send!

Sure, sorry for that.

	- Andreas

[CC'ed to the list, in case others had similar difficulties.]


                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.

Re: [Sml-implementers] Subject: Standard ML

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

At 17:04 25/09/2001, Andreas Rossberg wrote:
>Matthias Blume wrote:
>> Well, that settles that.  Sounds like "Standard ML" is soon to be officially
>> dead.  Ideas for a new name, anyone?
>
>How about continuing a good tradition in naming PLs and call it "Robin"?

Surely "MiLner" (or "MLner") fits the tradition better?

I'm rather amused by the idea of naming a language after someone who
apparently wants nothing to do with it ;-).

Dave.

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

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

At 07:20 27/09/2001, Andrew Kennedy wrote:
>SML is not yet dead
>...
>(In no particular order)
>Moscow ML, SML/NJ, TILT, Church Project, MLton, Poly-ML, 
>MLj, SML.NET

I'm having another attempt to get Global Graphics Software (ne Harlequin)
to release the source of MLWorks.  But I'm not going to hold my breath
while I'm waiting.

Actually, I don't take the number of implementations to be such a sign of
strength as you do.  While it shows that the Definition of SML is a great
standard to co-ordinate implementations of the language, the paucity of
libraries suggest that the language is not so great for users.  (The slogan
could be: "So many compilers, so few users").

I hope that we can agree on the compilation management and FFI issues.
Then people will be able to share libraries between all these
implementations, and SML might get more users.

Dave.

Re: [Sml-implementers] Developing ML

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

Hello Robin,

Thank you for taking the time to explain your position.  You have convinced
me of one major point, but I disagree with others.  In particular I don't
agree that your position "liberates ML instead of ossifying it".  I hope
that I explain my reasoning as carefully as you explained yours.  I also
propose a way forward, which I hope might form the basis of an acceptable
compromise.

The major point that you have convinced me of is that there is a particular
risk in any non-trivial changes to the semantics.  If such a problem arose,
one immediate effect would obviously be to reduce the confidence of users
in the language itself.  They may not make the distinction between the
language they are using and the language defined in The Definition of
Standard ML, thus attributing blame to innocent authors.  A more pernicious
effect would be if they also lost confidence in the advantages of the
formal definition process itself.

The first point I want to make in reply is that the discussion on the
sml-implementers list is attempting to find consensus between implementors
on how they want to develop their implementations.  So your statement that
"different paths can be taken" and that these paths can explore different
semantic styles, is not relevant to this particular discussion.  Although
it is undoubtably true to the broader development of ML,  any immediate
developments from this discussion will be bound tightly to The Definition.

The second point I want to make is that the difference between a new
language and a revision to the existing language is, to some extent, in the
eye of the beholder.  In other words, none of us can prevent people from
treating a specification as a revision of Standard ML, whatever name we
call it.  Let's consider your other example of how ML might develop:

>One natural path would be a
>short one, identifying a set of alleged shortcomings in SML and
>proposing improvements, with (as Andrew suggests) semantics in the
>style of - and with reference to - the '97 SML Definition.  It could
>be called - say - ML2002; not being called SML there is no need for
>complete consensus on this path, and indeed some implementers and
>users may well prefer to stay with SML.  

If we define a small set of changes to SML 97, ensuring backwards
compatibility with SML 97, and using the same formalism as SML 97, where
these changes are supported by the vast majority of extant implementations
of SML 97, then in my opinion you have a de facto revision of Standard ML,
whatever we might prefer it to be called.  It would be a case of "if it
talks like a duck, walks like a duck and quacks like a duck, then it is a
duck, but you have to call it a goose".  As a concrete example, if we
present (SML 97 + vector literals, withtype in signatures, and compilation
management) as a complete new language, our readers/users will recognise it
for what it is -- a minor revision of SML 97.  W

As you note, consensus is a vital part of this.   If one or two
implementations support these features, they remain isolated extensions to
the language.  If 9 out of 10 implementations support them, then they
become a revision of the language simply by existing.   The word "Standard"
in the name is important.

My third point is that there are some changes to the Definition that we can
have confidence in.  For example, a new derived form is highly unlikely to
break anything.  Neither is a new class of special constants.  (In each
case, I'm supposing that we don't make mistakes with the syntax of the
features, but syntactic mistakes are not in the same class as the
possibility of unforeseen semantic interactions).

My fourth point is that a revision to the language would not invalidate the
existence of the 1997 Definition of Standard ML, just as that did not
remove the 1990 Definition from history (and indeed some implementations
continued to support SML 90 as an option).  Nor (since I'm assuming
backwards compatibility) would it invalidate existing books and libraries
in the way that the 1997 revision did.  (Of course the books wouldn't be
completely up to date, but this also applies to the development of new
libraries, or to a standard for compilation management).   You can see the
same thing in other languages -- K&R C is a different beast from ISO C,
which is different from C9X. 

My fifth point concerns only your "tension #1", between evolution and
stability in general.  You say, "If you evolve (the Definition of) the
language itself, then you abandon a stable platform".  I don't agree that
there is a clear difference between the language and the rest of the
platform, i.e. libraries, FFIs, compilation management, and so forth.  To
take a concrete example, if some implementors develop a common interface to
C code, and I take advantage of that, then my code is limited to those
implementations.  If that interface then changes, I may have to adapt my
code to match.  Or if someone writes a better C interface, I have to decide
whether to change my code or stick with the lesser library.  The same thing
applies to a GUI library or a database library or any other library
(although it is particularly relevant to libraries that require some
support from the implementation itself, such as FFIs).  The tension #1 that
you describe is always present, and does not fit a clean separation between
language semantics on the one hand, and libraries on the other.

My final point is that the Definition contains some ambiguities.  This is
not a criticism of the work you put into writing it; in a project this size
some ambiguities were inevitable.  But as Andreas's recent message shows,
they do introduce observable (if small) differences between
implementations.  Implementors may well want to agree on minor changes (or
interpretations) to the Definition to resolve these ambiguities.


So can we find a common ground in which we can evolve "Standard ML" without
risking the problems that you warn of?  (Assuming that the implementers can
reach agreement between ourselves, of course, which is yet to be proven).
I think we can: the key is to minimise the risks to stability, to manage
expectations, and to clearly delineate authorship.

First, we need to ensure backwards compatibility with SML '97.  There was
some discussion on the list of simplifying parts of the language, or
removing unwanted features.  I think we have to leave such changes to the
development of new languages.  This assures a degree of stability, and
reduces the problems of books becoming out of date.

Second, we have to be conservative with changes and extensions.  I think
the discussion was already well down that path in any case.  But this is
not the same as banning any changes to the language.  Ambiguities should be
resolved (where possible), and changes such as vector literals (special
constants), or-patterns and functional record update (derived forms?), and
perhaps laziness can be made without incurring risk.

Where new language features are introduced, the document that describes
them should explain why we believe they are safe.  E.g. it could explain
that derived forms do not threaten the integrity of the language.  For
larger changes, it could point to extensive use in some implementations
before the feature was adopted as a standard, and/or to theoretical work
that proves certain properties hold in the context of the entire language
(not just a mini-language).

Finally, whenever a new feature is introduced, the parties agreeing to the
introduction should clearly state their responsibility for the decision.
They should also offer you (and other authors of SML 97, where appropriate)
a disclaimer to make clear that you have not taken part in this new revision.

With this process (or something similar), I believe we could evolve
Standard ML in a controlled manner.  The main thrust of the evolution would
be to support compilation management, a C FFI, and library development, but
the evolution could include the resolution of ambiguities in the Definition
and the addition of small but useful language features.

One current topic that may need more work is the interaction between
sharing and type abbreviations in signatures, which has turned out to be
more of a problem in practice than expected.   This actually supports your
arguments in favour of conservatism, in that we want to avoid such problems
in future.  For now, though, we have to deal with the problem we have.  I
think it's worth trying to improve this situation, if it can be done safely
(bearing your warnings in mind).

From a personal perspective, the above process doesn't take us as far as I
would like to go.  I think that some support for higher-order modules
and/or recursive modules is highly desirable from a practical point of
view.  But clearly it would be hard to add these features within the above
process.  Perhaps we can cross that bridge if we come to it.  

Best wishes,

Dave.

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

[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

[Sml-implementers] evolution from Standard ML: division of a community?

[Mads T. <to...@it...>]

Some messages on the list have suggested that insisting on keeping
Standard ML as it is leads (or has led) to a division of the (Standard)
ML community.

It does not have to be so.

Like Robin, I believe it is essential for that community to have the
stable platform (Standard ML) that is separated from the evolution into
new platforms. 

But no-one is suggesting that any person in the Standard ML community
has to take sides, i.e., that there should be a division of the ML
community into two fractions. The same person can of course engage in
work that sticks to the Definition of Standard ML and at the same time
engage in other activites that aim at creating a new platform, a
successor to Standard ML.

If that new platform turns out to be a big improvement over Standard ML,
maybe someone will take the trouble to write a new formal definition (or
revise the 1997 Definition - which is fine by me, as long as the changed
language has a different name). Maybe authors of textbooks will decide
that it is worth revising their books and maybe their publishers will
agree. Maybe those of us who have Standard ML compilers written in
Standard ML will take the trouble to migrate. Maybe those of us who have
SML software that is used in real-life applications (that we depend on
vitally for our other business) will decide that we want to port our
code (not that I know where the time to do it should come from).

And if the new platform turns out not to be such a big improvement, or
fails to appear, no harm is done, neither to Standard ML nor to those of
us who depend on Standard ML as a trusted programming platform. 

I think it is reasonable that the onus is on those who want change. They
have to define what that new platform is. When that is done, they have
to convince others that their new platform is a sufficiently significant
improvement over the existing one to warrant migration of compilers,
books, libraries and everything else (which, presumably, the proponets
of the new platform are not going to do themselves). Some people have
worked very hard to obtain compliance with the 1997 Definition. Those
people cannot be expected to sign a blank cheque for a process of
change. For example, as a compiler writer, I would like to see what that
new proposed platform is, before I decide whether I want to modify the
compiler.

No-one is out to separate people, only to separate concerns: I argue
that we must stage the evolution of ML in such a manner that Standard ML
represents one particular, completed stage in the evolution of ML, a
stage that will remain viable while some people work on a successor to
Standard ML.

Regards,

Mads Tofte

[Sml-implementers] Developing ML

[Robin M. <Rob...@cl...>]

I've read most of the recent discussion (various people have kindly
copied or forwarded messages to me, as I'm not a regular member of the
list).  It's clear that there is considerable interest in advancing -
or advancing from - SML.  Andrew's and Bob's categorisations show that
the range of topics to look at is multi-dimensional.  I agree with
those who say that languages evolve.  My view, expressed in a joint
message with Mads Tofte, is that we need evolution _from_ SML, but not
evolution _of_ SML.  I want to explain this position.  Mads has
recently been both an implementer and a user, which I haven't, so he
may well explain it differently.

The SML project was conceived as an ambitious attempt to bridge the
gap between real-world programming and fully formal language
definition.  To succeed, we had at least to show that rigorous
definition would actually confer benefit on programming practice. In my
view we did succeed; the unambiguity of the semantics made it
absolutely clear what users were getting, its near-determinism made
porting of programs between implementations reasonably feasible, and
its stability over many years relieved implementers of at least one
kind of headache.  The need to make a complete definition also
clarified the language design.  So we can claim to have made it more
reasonable for real languages to aspire to a formal semantics.

Of course the project had a tension built into it from the start,
between the rigour required of a formal definition and the freedom to
evolve.  The success hasn't resolved the tension, but made it more
visible.  In fact, there seem to be two tensions; one (#1) between the
wish for evolution and the need for stability (which can only partly
be solved by backward compatibility) and another (#2) between the
evolution of a language and the evolution of its semantics.

I think implementers have differing views on how to resolve tension
#1, i.e. how to weigh evolution versus stability, and this fact is
part of the reason for my position.  If you evolve (the Definition of)
the language itself, then you abandon a stable platform; if you evolve
_from_ the language then you preserve the platform and allow true
evolution - i.e. different paths and different speeds of development.

But tension #2 is also part of the reason for my position, and I want
to say more about it because nobody has said much.  There is a
mismatch between our ability to evolve programming language (which
runs pretty close to our ability to evolve natural language) and our
ability to adapt formal definition accordingly.  Although people know
a lot more how to write semantics than 20 years ago, we don't yet know
how to do it in a way which supports change easily. (This is a
specific and difficult instance of formulating software specifications
which support change.)

 Take the '97 revision of SML as an example.  We aspired to a modest
set of changes, and yet to bring the formal definition in line with
them was a large task in proportion; Mads Tofte and I wrote most of
the `code' of the Definition and we probably understand this more than
most. The result wasn't perfect; I trust the '97 Definition more in
some respects, but less in others respects, than the '90 semantics.

Why is it difficult to adapt a formal definition to change?  In
undergraduate lectures on "Designing and Defining a Language" I point
out that every worthwhile language juxtaposes features which are well
understood separately but not understood in juxtaposition.  (If they
were, the language would exist already.)  A good example is the
interaction (not originally understood) between updating (understood)
and simple polymorphism (understood).  These interactions are
reflected by non-orthogonalities in the semantics which in turn render
the semantics vulnerable under change; relatively small changes in
language can permeate large parts of the formal definition, and thus
degrade confidence.
  
Bob says "IMO the 1997 revision was hobbled by an excessive emphasis
on the needs of The Definition without due consideration of
implementation or application."  My view is quite different.  True,
because of the need to get a sound definition with limited available
effort, we knew we could only afford to address a few changes (because
of the permeation phenomenon).  But the "needs of the Definition"
arise precisely from a concern for implementation and users, because
of the benefits which sound definition confers.

If you're still with me, let's go back to tension #2, between evolving
a language and evolving its definition.  I've argued that the latter
is (a) harder and/or slower, and (b) liable to degrade quality.
Putting this together with my remarks about tension #1 (between
evolution and stability), I am convinced that Standard ML should
remain as it is; a reasonably solid platform from which different evolution
paths (of even just a single path if there is consensus) of language
can be taken.  Therefore I would not accept an evolution _of_ Standard
ML itself.

Far from killing or ossifying ML, this liberates it.  This is because
(a) different paths can be taken, with names which reflect membership
of the ML family; and (b) these paths can be followed either with or
without providing formal semantics, or perhaps exploring different
semantic methods (e.g. type-theoretic).  One natural path would be a
short one, identifying a set of alleged shortcomings in SML and
proposing improvements, with (as Andrew suggests) semantics in the
style of - and with reference to - the '97 SML Definition.  It could
be called - say - ML2002; not being called SML there is no need for
complete consensus on this path, and indeed some implementers and
users may well prefer to stay with SML.  

If there's one thing that the SML development over the last 18 years 
has shown, it is that consensus is a luxury!

Robin Milner

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...>]

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

[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

[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] Free type variables on toplevel

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

This sounds like a nice solution.  I'm glad that my speculations on why it
might be hard were wrong.  Do other compilers do "top down" signature
ascription in this manner?

Bob

-----Original Message-----
From: David Matthews [mailto:Dav...@pr...]
Sent: Thursday, September 27, 2001 9:21 AM
To: 'Matthias Blume'
Cc: sml...@li...
Subject: RE: [Sml-implementers] Free type variables on toplevel


On Wednesday, September 26, 2001 7:41 PM, Matthias Blume
[SMTP:bl...@re...] wrote:
> As for the simultaneous type-checking-and-constraint-applying
approach:  Why
> can
> one not work with unbound type variables (just like when type-checking
a
> "let")?
> As I understand, that's what OCaml does.  Of course, I do not agree
with
> OCaml's
> solution of simply leaving unbound type variables in the final type; I
have
> explained
> why.  (It would not be a good idea in the context of separate
compilation.)
> What I am suggesting here is to leave the variable _tentatively_
unbound.
> At the end of the day, when the whole topdec including all its
signature
> constraints
> etc. has been considered and there are _still_ free type variables in
the
> result,
> then we reject the program.  But not before that.
> 
> Matthias

When I implemented this in Poly/ML I thought along similar lines and
this is a fairly accurate description of the current implementation.
The note to rules 87-89 says that no free type variables enter the basis
and this is enforced in the compiler by a final walk over all the
structures, functors and values.  Until then the variables are unbound.
Variables that don't appear in the result signature, such as those that
have been shadowed, are simply ignored.

> structure S:
sig
	val x: int list
end
=
struct
	val x = ref nil
	val x = nil @ nil
end;
# # # # # # # # structure S : sig val x : int list end

The original implementation in Poly/ML produced an error message and
failed if a free type-variable was found.  I changed that in a later
release to a warning and the type variables are unified with new unique
types.  The reason was much as Bob described.  To avoid confusion with
existing types or with type variables the types print with the (illegal)
identifiers _a, _b etc.

Without the signature:

structure S =
struct
	val x = ref nil
	val x = nil @ nil
end;
# # # # Warning:
The type of (S.x) contains a free type variable.
Setting it to a unique monotype.

structure S : sig val x : _a list end

David.


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

RE: [Sml-implementers] Free type variables on toplevel

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

For implementations based on type quantification and type interpretation,
dangling top-level type variables *have* to be instantiated before execution
--- otherwise you have an unbound (type) variable to deal with.  Abstracting
it is not an option, because it would violate the value restriction (in
general) and change the semantics.  For example, nil@nil would be a value!

Regarding the scope of resolution for record patterns and overloading, it is
reasonable to require this to be the nearest enclosing val binding.
However, we should take a poll to see whether this is the choice that has
been adopted in most implementations.

Although these are small issues, they illustrate well the need for the
language and its definition to evolve, de facto or de jure.

Bob

-----Original Message-----
From: Andreas Rossberg [mailto:ros...@ps...]
Sent: Thursday, September 27, 2001 6:32 AM
To: Peter Sestoft
Cc: Andrew Kennedy; sml...@li...
Subject: Re: [Sml-implementers] Free type variables on toplevel


Peter Sestoft wrote:
> 
> However, it is confusing (and probably a mistake) that Moscow ML
> currently accepts free type variables in structure declarations in the
> interactive system:
> 
>    - structure S = struct val i = rev o rev end;
>    ! Warning: Value polymorphism:
>    ! Free type variable(s) at top level in structure identifier S
>    > structure S : {val i : 'b list -> 'b list}
> 
> Note that 'b in the type of S.i is not universally quantified.

IMHO the confusion could be reduced by not using ordinary type variable
syntax for reporting "undetermined types".

But apart from such cosmetics, the behaviour of Moscow ML's toplevel is
absolutely reasonable, IMO. And I believe, as I tried to explain in my
post, that strict reading of the Definition does not allow any other
behaviour (although that might not have been the intention of the
authors).

OTOH, for compilation units, Andrew's proposal and Moscow ML's approach
of rejecting undetermined types seems the only sensible thing to do.
This is something that has to be specified along with the separate
compilation mechanism. I even think it should be enforced that every
compilation unit has a syntactic signature (i.e. one that can be
expressed within the language, precluding e.g. hidden types etc.).

> The question of how much context to take into account has existed for
> years, namely, when resolving operator overloading and flex records.
> The Definition only specifies that at most the enclosing
> structure-level declaration should be taken into account.

For flexible records the Definition does not even say that the context
for resolving it might be limited by an implementation, although
unrestricted context is incompatible with let polymorphism. This
arguably is more or less a bug. In any case I strongly vote for fixing
any such source of implementation-dependent behaviour. The natural
choice in the case of overloading and flexible records seems to be the
smallest enclosing value declaration.

	- Andreas

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