Re: [Sml-implementers] compilation management

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

"Daniel C. Wang" wrote:
> 
> At 05:01 PM 9/18/2001 -0700, Stephen Weeks wrote:
> >{stuff deleted}
> >Here is my main requirement for a standard compilation management system that
> >specifies how to build applications:
> >
> >>From a description of an application, it should be easy to extract an SML
> >program consisting of all and only the modules that are needed for the
> >application.  (This extraction may require renaming modules.)  In fact, that is
> >one way to define the dynamic semantics of the compilation management system --
> >by translating the description of the application into an SML program.
> >
> >By "easy", I mean that the extraction should be possible without looking at any
> >SML sources, only by looking at the application and library description files.
> 
> Let's just keep things simple, and get everyone to adopt CM. I've talked to
> Matthias in the past about having a "dump everything to one big SML file"
> option for CM. It's not that hard to do. Making CM independent of the
> underlying SML/NJ compiler will probably take some more work, but much less
> work than trying to reinvent yet another compilation system.
> 
> This suggestion violates Steven's "easy" requirement. However, I think that
> by making things "easy" for the tool it must make things harder for the user.
> I'm happy as things are now.. where I just list a bunch of SML files in any
> old order in my sources.cm and type CM.make().

Obviously, I have a natural bias in favor of CM. :-)  But I actually agree with
Steve (and others) to some degree.  Getting everyone to adopt CM is a bit too
ambitious, I think.  More realistic is a simple exchange format that specifies
precisely which files get compiled in the context of what bindings imported from
where.  I have ideas as to what this format could look like.  As you might imagine,
CM internally computes all this information anyway, so dumping it into an
ASCII file will not be hard at all.

It is my plan to design a low-level format that I believe all SML implementors could
easily support without having to do fancy things such as dependency analysis etc.
The format will also provide the necessary information for the transformation into
pure SML that we described in our TOPLAS paper (where it was also used to define the
dynamic semantics of CM).

> Even for very larger systems, I see no advantage to having the user provide
> any more information than a list of files and perhaps an export list
> of identifiers.

Right.  I see no reason to give up CM or its model in SML/NJ.  But I can modify its
implementation in such a way that a more explicit low-level interchange format can
be produced (and even used internally) by it.

> I am a CM bigot... so perhaps there are some strong concrete technical reasons
> I'm ignoring... but unless there are I don't see any reason not to just adopt CM*.

I am all for adopting CM.  But the current implementation will probably be hard to port
because it "knows" an awful lot about SML/NJ.  Plus, the bulk of the code is not
concerned with simple dependency analysis anyway.  (I can imagine ripping out the
dependency analyzer, but that's on the order of less than 500 lines of code anyway.)

Matthias