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

[Matthias B. <bl...@re...>]

Robert Harper wrote:
> 
> More generally, I would like to open discussion about more extensive changes
> and extensions to Standard ML.  What do the readers on this list think
> should be done next in the evolution of the language?
> 
> Bob Harper

Not being a type theorist by any stretch of imagination, I am not sure whether
there will be fundamental problems with the following.  But in my (and I should
say "our") recent practical experiences with the ML module system, the notion
of "where type" and its ramifications ("rigid types", no sharing specs allowed
for them, etc.) seem arbitrary and turn out to be extremely bothersome in practice.
Having "where structure" (which turns into a whole-sale set of "where type" specs)
around compounds this problem.

Both Lal and I independently ran into this recently when trying to
restructure significant pieces of ML code.  My current resolve is basically to
stay away from functors as much as possible, and to use only "sharing" specs
unless I absolutely cannot avoid a "where type".

So here is my question:  Why can't "where type" in any disguise (type abbreviations
in signatures, "where structure")  and sharing specs all work the same way and be
used in any order.  Intuitively, one would expect every "where type" and every
"sharing type" to throw another constraint into a global pool of type equality
constraints where they get propagated as one would expect.

What is the rationale for the current non-symmetric design?  Is it easier to specify?
Is it easier to implement in a compiler?  Or does what I am asking for not make sense
at a more fundamental level?

Matthias