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

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

At 16:27 10/09/2001, Stephen Weeks wrote:
>> The official definition of structure sharing is useless; 
>
>This is an overstatement,

Indeed, the official definition of structure sharing satisfies one clear
requirement: it simplifies the porting of SML'90 code to SML'97.  The
original draft of SML'97 deleted the structure sharing construct
altogether, and one of the reasons for keeping it as a derived form was
precisely to simplify the porting of SML'90 code.  Of course, SML'90 didn't
allow type abbreviations in signatures, so the problems found by the TILT
team didn't arise.

>although I would agree that the effect of the
>definition is to strongly encourage a programming style in which type
>definitions do not appear in signatures. 

Given the history, the intent might have been more to discourage a
programming style that uses the structure sharing derived form.
Personally, I find it occasionally useful, e.g. when a structure contains
all the type definitions for a type checker or for an abstract syntax, in
which cases the large number of type sharing equations would be unwieldy.
If MLWorks ever makes it to open source (which seems unlikely after all
this time), I'd be happy to implement a more permissive regime.  Of the
choices offered by the TILT team, I would be conservative and plump for the
error option.

Should we also consider supporting "where structure..."?  And perhaps
removing the "and" derived form of "where type...", which I believe is
ambiguous.

Dave.