RE: [Sml-implementers] Structure sharing and type abbreviations

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

I tend to agree with much of what Dave says here about the top level, which
is why I raise the issue.  In many ways the typical SML top level is not
even as good as a Scheme top level, eg in not supporting post hoc
re-definition of top-level functions.  Personally, I think that the
importance of top-level development is overrated, and can even be
counterproductive, but for those who value that sort of thing, it's clear
that what we have is entirely inadequate.  I'd like to see the issue
separated out, however, from the more fundamental issues of language and
library design.

Bob

-----Original Message-----
From: Dave Berry [mailto:da...@ta...]
Sent: Sunday, September 16, 2001 10:17 AM
To: Robert Harper; 'Andreas Rossberg'
Cc: sml...@li...
Subject: RE: [Sml-implementers] Structure sharing and type abbreviations


At 15:00 14/09/2001, Robert Harper wrote:
>2. How much should the language be tied to the existence of an interactive
>system? 

The current notion of the top-level is a complete anachronism, and
positively hinders the development of a decent programming environment.  It
inherits from Lisp the concept of redefining a function in isolation from
the rest of the current scope, but this is unsuitable for a strongly-typed,
statically-scoped language like ML.  I believe that every definition in a
program should have a unique path that can be used to identifiy it, without
having to add any extrinsic information such as the line number within a
file.  This would have the corollary that no identifier could be redefined
in the same scope.  (Inner or outer scopes could contain other definitions
of the identifier, but they would have different paths).

Implementations could still provide an interactive development mode, but
they would require a different design from the naive approaches currently
used.

>3. Backward compatibility is an important issue, but should it be allowed
to
>ossify the language?  ...  Should there be
>a break with the past to clean up and move forward, or should we limit
>attention to only compatible changes?

Users really do value stability (see e.g.
http://www.dcs.ed.ac.uk/home/pxs/sfpw.ps).  Incompatible changes should
come in rare, large bursts -- e.g. you could define minor compatible
changes to clean up SML'97, followed by an SML'02 with more far-reaching
changes.

>2. Datatype's cannot be made transparent with seriously changing the
>language.  

By transparent, do you mean that the representation of a datatype should be
deducible from any type that it matches?  Or. to use another example, that
this snippet shouldn't elaborate:
          struct
	   datatype 'a foo = Foo of 'a * 'a
	   type t = 'a * 'a
	sig
	   type t 
            datatype 'a foo = Foo of t
         end
Isn't this what O'Caml implements?  If so, how do they avoid the problems
you encountered? I'm interested to read that you've changed your mind about
this.  Have you written up your experiences in more detail?

>7. First-class polymorphism raises problems for type inference.  There are
>some limited uses for it, in particular for existentials, but the cost
seems
>very high. 

Isn't it fairly easy to allow it if and only if the type of the function is
explicitly specified?

>9. At the level of syntax, I would support fixing the case ambiguity,
>eliminating clausal function definitions entirely, fixing the treatment of
>"and" and "rec" in val bindings, changing the syntax of handlers, and
>probably make a few other surface syntax changes.

I'd support making identifiers case-insensitive, simplifying clausal
function definitions to make them reasonable to parse (IIRC it suffices to
always require parentheses when defining infix operators), dropping the
optional type qualification in "x:ty as ...", and making all structures,
functors and signatures share the same name space.

Actually, I'd like a completely redesigned syntax that is more familiar to
mainstream programmers.  

>Having said all this, let me mention the most difficult, over-arching
>problem: what is the means by which these (or other) modifications would be
>specified and implemented in a practical compiler?  How would these ideas
>(or others that we may agree upon) be made "real"?

Those are two questions: specification and implementation.  For
specification, a web site seems the best bet.  I don't know whether it's
possible to get the copyright of the definition back from MIT, but it would
be useful to have either that or an equivalent specification on the web.
Then updates could be announced and tracked easily.  Regarding
implementation, there are many (possibly too many) SML compilers, but
perhaps if we have a common interchange format for libraries, it would be
easier to share at least the front-end of a compiler.

>Finally, let us not forget that the mere existence of a rich collection of
>libraries is at least as important as fixing the last 10% of oddities in
the
>language, or eking out another 2% performance on certain specified
>benchmarks.

In my experience there is far more than 2% of performance to be eked out,
unless you've got cross-module optimisations working at last.  And
libraries can drive the requirements for language changes -- e.g. Okasaki's
work (among others).  In fact, maybe that's the best way to drive language
requirements.

Dave.