Re: [Sml-implementers] compilation management

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

Dave Berry wrote:
> 
> (I see you've beaten me to some of the questions I ask in this message).
> 
> Some questions about compilation management.
> 
> 1.  How much do we want "backwards compatibility" with each existing
> implementation?  On the one hand, we want to minimise the work needed to
> adopt the new system.  On the other hand, everyone will have to make some
> changes, and there might be benefits from requiring more than just the
> minimum.

I think that the mechanism that we will hopefully agree on is going to be
low-level enough to accommodate everyone's needs.

> 2.  Shall the new system require a top level?  Preferably not, IMO.

That's a totally different question.  I prefer supporting an interactive
toplevel in form of an application library.

> 3.  Should we adopt a common suffix for file names?  E.g. ".sml" for
> structures and functors; ".sig" for signatures.  The advantage is
> uniformity in tools.  The disadvantage is more changes for some users.

I don't think that we should _require_ particular suffixes.
 
> 4.  Should we require one module per file and use the same name for the
> module and the file?   The advantage is that it's easy to find modules,
> easy to explain to new users, and a library file doesn't have to choose
> between listing modules and files.  The disadvantage is more changes for
> some users.

No, absolutely not.

> I'm strongly in favour of this. Apparently some people see this as a gross
> imposition. I don't even begin to comprehend why they feel this way, but I
> guess we have to accept their view.

Here are a few reasons:

-- I (and others) often write multiple "modules" in one file (e.g., signature and functor).
-- File systems are often limited in what names you can choose.  The limitations are not
   uniform from OS to OS (or even just filesystem to filesystem).
-- Not requiring a fixed mapping is more flexible during program development.
-- In a world without fixed mapping, a fixed mapping can always be adopted using
   convention when this is desired.  But the other way around this does not work.
-- The benefits from having a fixed mapping are, IMO, rather marginal.

> 5.  Should we make any file into a module?  I.e. if a file contains a set
> of top-level declarations,  this would be equivalent to defining a
> structure with the same name as the file.

Again, absolutely not!  (This is the same thing as above just with one or two fewer lines
in the source file.)

> OCaml gets a huge win from this simple mapping from files to modules; I'm
> sure this is one of the design decisions that makes it popular.

Hmm.  "Huge"?  How do you measure that?

> 6.  Should we support multiple configurations -- e.g. release mode and
> debug mode, where the two modes apply a certain functor to different arguments?

This can be taken care of by conditional compilation.

> 7.  Should we support conditional compilation?

Probably.  (CM does.)

> 8.  Should we standardise the semantics of "use", for those systems that
> provide a top level?  Peter Sestoft analysed the different implementations
> at the time of SML'97.

If we adopt the point of view that the interactive toplevel is an application library,
then this is clearly a problem of that library.  Thus, maybe we can defer this decision.

Matthias