Re: [Sml-implementers] extensions to SML

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

Hi Bob, 

Robert Harper <Rob...@cs...> writes:
> What is clear to me is that it is more than time to renew emphasis on
> revision and extension of Standard ML, for several reasons.  First, there is
> a crying need, as is clearly evidenced by this discussion.

Yesterday evening I took some time to carefully read all the messages
in this avalanche of emails.  And I've come to a different conclusion
than you.  Several people have raised the opinion that they would prefer
that *no* revisions was made to the Definition, and if revisions *had*
to be made they should be kept minimal.

It is also clear (to me at least) that many of the participants in
this discussion don't feel that they have as big a vote as you in
these matters.  There might be different reasons for this felling: you
are one of the authors of the Definition; or that we don't have
time/skills/energy to participate in a revision of the Definition.

> Second, many of the proposed revisions are entirely do-able within a
> reasonable time frame.

That revisions are do-able does not necessitate revisions.

> Third, it is essential for Standard ML to remain a viable language.

I don't think that the Definition need to changed for SML to remain a
viable.

One of the main strengths of SML is that the language don't change all
the time.  

Our disagreement might boil down to what we mean by "a viable
language"?  If you mean a viable *research* language then I might
agree with you.


> I propose, therefore, that we focus our efforts on (1), leaving aside
> discussion of more ambitious projects (which I, among many, wish to
> undertake) for another day.

Reading this sentence again I realize that we might be in perfect
agreement, but I'll rather speak up than having doubts.


> Reviewing the discussion, I can see a few major topics for immediate
> consideration.
[snip]

> 2. Standardization of a substantial set of libraries.

But we don't want to repeat the fiasco of the Standard Basis Library
(for those involved, apologies for being so blunt).

I think that the process of designing libraries should be much more
open, like for example SFRI:
        http://srfi.schemers.org/
This way the *users* of SML get a say as well.

 
> 4. Extensions and modifications to the language itself.  These include
> relatively trivial things like denigrating obsolete mechanisms (such as
> abstype), re-considering the semantics of structure sharing (which started
> this discussion), and adding support for new features (eg, updateable
> records, lazy evaluation, vector expressions, richer patterns, hierarchical
> extensible sums).  I think there are strong arguments for all of these
> changes.  We might also consider ways to improve the syntax while providing
> a path for porting old code.


Before we start to make changes to the language (minor or major) I
think we should first try to define *what* we want to achieve.  To
quote from the (revised) Definition (p. xii):

   ... But we have only made such amendments when one or more aspects
   of SML---the language itself, its usage, its implementation, its
   formal Definition---have thus become simpler, without complicating
   the other aspects.

Other goals for our discussion are of course also valid:

   * There should be *no* changes to the definition, only to the
     "environment" of the language (compilation management, libraries,
     ...)

   * Make SML more popular in education/industry/research

   * Make SML better for text processing

   * Make SML better for number crunching

   * Make SML the best language for web-programming

   * Attract Open Source developers

   * Make SML the language of choice for system programming

   * Simplify the syntax

   * Include Ken's favorite extension (first-class modules or withtype
     in signatures, I don't know which one is my favorite ;-)
 
   * Recast/rewrite the official Definition in a different
     mathematical framework.

And the list could go on.  Some of these goals can be met at the same
time, some goals are clearly to "specific", and some goals are in
conflict with each other.  All the more reason for discussion *what*
our goals should be.

To quote the Definition again, to which you are an author, you say
(p. xiii):
        
   ... This is the first revised version, and we foresee no others.

This sentence gives me the felling that the other authors don't agree
with you, when you say that "there is a crying need" for revision.


> Perhaps it is worthwhile to state a few principles that I hope can
> guide us.

> 1. Standard ML exists independently of its implementations.
[snip] 
> 2. Revisions must be guided as much by the experience of users and
>    implementors as by the demands of a clean formal definition.
[snip]
> 3. It is important to achieve a rough consensus, but complete
> agreement on all issues may be impossible to achieve.  We will need
> to have a mechanism for reaching a decision in the face of
> disagreement.


I agree with you on these principles but I don't agree with you that
there *have* to be any changes to the Definition (except for withtype
in signatures of course ;-)

So I think we should perhaps discuss what we when/if we disagree.


Cheers,

--Ken Friis Larsen