sml-implementers

[Sml-implementers] compilation management

[Stephen W. <sw...@in...>]

I like Bob's division into four pieces.  To get the ball rolling on 1 ... I
agree with John when he says

> The important problem is to have a standard mechanism for specifying how to
> build libraries and applications from sources.

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.

Re: [Sml-implementers] compilation management

[Daniel C. W. <dc...@ag...>]

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

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.

Anyway, as a first cut someone should take some version of CM and modify it so
that it compiles independently of SML/NJ and simply dumps one big SML source file.
Perhaps, later on we can figure out how to disentangle the current CM from SML/NJ
and have others integrate it into the guts of their systems.

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

*A question arises about which CM the "classic" version that ships with the stable 
SML release or the new CM. I think, it would be prudent to just stick with the
"classic" version as a first cut, and migrate to the "new" CM later on.

 

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

Re: [Sml-implementers] compilation management

[Daniel C. W. <dc...@ag...>]

At 10:27 AM 9/19/2001 -0400, Matthias Blume wrote:
{stuff deleted}

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

I guess there are two issues.
 1. A portable low-level build script mechanism that is easy for any 
    implementation to adopt, whose goal is to reliably reproduce a build. 
    It really should not be too much fancier than "use" with 
    symbol import and export info. It would be useful if these build scripts 
    can be composed in a limited way like sources.cm files can be.

 2. A standard way to generate these "build-scripts" from source files.

The answer to question 1, should be easy to agree on.

For 2, the long run answer should be CM, because I see no reason to adopt
any other model when the CM model. It is quite well tested and superior to
all the existing approaches in all the existing ML implementations, from
a user standpoint. 

I feel #1 is only a stop-gap until CM becomes a standalone SML program that
can generates these build scripts for all implementations. At that point
the build-script language is just some silly intermediate form that end
users should be completely oblivious to.

In the not to distant future, I hope their is one user visible build mechanism
and it should look a lot like CM. Point 1 should be addressed first  
but at the end of the day point 2 is the only one that matters to end users.