Re: [Sml-implementers] compilation management

[John H. R. <jh...@re...>]

In message <4.1...@po...>, Dave Berry writes:
>
> (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.  

The important thing is to make it easy for library/application authors
to target the interchange format.  The build mechanism needs to be
compatible with the SML implementations, but I don't think that we should
worry too much about compatibility with existing build mechanisms.

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

I agree.

> 
> 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. 

No.  The design should not introduce unnecessary barriers to porting
existing libraries.

> 
> 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.
> 
> 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.

Because it adds an uneccesary restriction on my programming.  There are a
number of things that I do regularly, which are incompatible with
this requirement.  I often want to put a signature and implementation in
the same file, have multiple structure definitions in a file, or have multiple
implementations of the same module in a directory (see conditional compilation
below).  Also, the language allows arbitrary-length structure names, whereas
some operating systems impose tight restrictions on file-name lengths.

> 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.  The advantages are that novices
> are using the module system as soon as they start using files, and the
> module system is both natural to use and easy to explain, and we don't have
> to worry about supporting "core-only" programs.  The disadvantage is that
> users have to add the structure header when adding an explicit signature
> constraint, or when writing a functor.  
> 
> 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.  OCaml
> doesn't yet support functors or generic signatures as cleanly, but we can
> do better.

I don't see a strong need for this change.

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

We have found conditional compilation useful in CM, but mostly as a way to
support multiple versions of the compiler in a single sources.cm file.
I suspect that once a library is targeting multiple implementations of SML,
it will need some mechanism to customize the build process.  Such a mechanism
could address #6 too.

> 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.
> 
> 
> 
> _______________________________________________
> Sml-implementers mailing list
> Sml...@li...
> https://lists.sourceforge.net/lists/listinfo/sml-implementers