[MLton-devel] Re: SML Basis Library (fwd)

[Matthew Fluet]

I got the following back from John.  I did add a final line to my e-mail
asking for an update to the sml-implementers list, so maybe one is
forthcoming.  (I got a weird bounce earlier today on a message to
mlton@mlton.org.  I know SourceForge mail is going down today, but it
wasn't supposed to be until 4PM Pacific.)

---------- Forwarded message ----------
Date: Thu, 14 Nov 2002 11:35:31 -0600
From: John Reppy <jhr@cs.uchicago.edu>
To: Matthew Fluet <fluet@CS.Cornell.EDU>
Cc: erg@research.att.com, jhr@cs.uchicago.edu
Subject: Re: SML Basis Library


I would like to wrap up the specification into a state that it can
be published.  To this end, we are looking mostly for minor corrections
in the specification and obvious omissions.  Changes that would break
current practice need a strong argument of support

BTW, your comments have been quite helpful.  Getting settled in my new
job has been very time consuming, so I haven't had time to fully address
them, but thanks for the help.

In the long run, the specification is not meant to be a "static" document
(unlike the Definition of SML).  We expect and hope that it will evolve
and grow.  To that end, there should be a steering committee with
representatives from the major players to maintain the specification.
Changes to specification come in several forms:

  1) correction to broken features.

  2) new APIs

  3) additional operations to existing APIs

  4) incompatible changes to existing APIs

  5) deletion of depreciated features/APIs.

For the sake of stability and backward compatibility, 1, 2, and 3 should
be the most common form of change (and I hope that 1 never happens).
Any new feature or API should be justified by some experience.

	- John


In message <Pine.GSO.4.44.0211141202100.24312-100000@snoball.cs.cornell.edu>, Matthe
w Fluet writes:
>
>
> John,
>
> Back in July, you posted the latest version of the SML Basis Library
> specification, stated that you felt the specification to be mostly stable,
> and asked that comments and discussions be directed at the
> sml-implementers list.  Since that time, there have been a few comments
> and requests for clarification, but little discussion.
>
> For me, and I suspect for others as well, it is unclear the degree to
> which the specification is up for discussion.  The fact that this was the
> first publicized revision of the specification since 1997 may have
> contributed to a false sense of fluidity.  While Cambridge University
> Press is reporting an October 2003 publication date, which seems quite a
> ways off, I'm certainly no expert on publishing.  It may also be the case
> that some members of the SML-implementers community feel that the design
> decisions were well hashed-out early in the drafting process and will be
> explicated in the final form of the specification.
>
> Still, if the specification remains in a flexible state, then it would
> seem that input from the SML community would be valuable.  My
> suspicion/hope is that other members of the SML-implementers community are
> waiting to follow your lead.  Certainly, no one else has the ability to
> accept or reject changes to the specification.  It would be a shame to
> miss an opportunity to improve this component of the Standard ML language.
> A note to the sml-implementers list clarifying the state of the
> specification and maybe a time-line of future milestones along its journey
> towards publication would be a welcome sight.
>
> Sincerely,
> -Matthew Fluet



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel