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

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

Personally, I'd much, much rather have "where type" (and "where structure",
with a per-type interpretation), than any form of "sharing".  I'd happily
live without "sharing" entirely, as long as I have type definitions in
specifications and "where type" to create these.  I use these mechanisms
entirely independently of modules, especially when I'm trying hard to impose
good abstraction boundaries between modules.  You don't need them very much
if you never use abstraction, and never use separate compilation (as
distinct from CM-like recompilation).  They do arise whenever you use
functors or enforced abstraction.

The ordering issues were raised, to some extent, in Derek's note.  The issue
is the scopes of type declarations.  Some very liberal forms of sharing
specification or where type specification can lead to "scope convolutions",
by which I mean that the "semantic signature" you get after elaboration
cannot be written down in the external language without very seriously
re-structuring the entire module hierarchy.  This is evil and pointless, and
should be avoided if at all possible.  The whole point about scoping (in any
form) is to avoid Fortran-like "global pools" of the kind you suggest.

Bob

-----Original Message-----
From: Matthias Blume [mailto:bl...@re...]
Sent: Friday, September 14, 2001 11:15 AM
To: Robert Harper
Cc: 'Andreas Rossberg'; sml...@li...
Subject: Re: [Sml-implementers] Structure sharing and type abbreviations


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