From Gene_Rollins@VISTA.VENARI.CS.CMU.EDU Mon Jul 27 15:00:06 1992
Return-Path: <research!VISTA.VENARI.CS.CMU.EDU!Gene_Rollins>
To: dbm@RESEARCH.ATT.COM
Reply-to: rollins+@PROOF.ERGO.CS.CMU.EDU
Subject: My visit to AT&T
Date: Thu, 23 Jul 92 14:56:17 -0400
From: Gene_Rollins@VISTA.VENARI.CS.CMU.EDU


We will be sending a draft of the Harper/Lee/Pfenning/Rollins separate
compilation paper later today.  Visiting AT&T next week is good for me.  I am
obliged to ask if CMU and AT&T can split the travel expenses for this trip.

The main question I want to discuss is "What should the separate compilation
system be for the next major release of SML/NJ?".  Even if we like the
long-term vision of the draft, it will be at least 6 months before it could be
fleshed out and implemented.  For the next major release, should we (1) use
SourceGroup v2.1, (2) revise SourceGroup and produce v3, or (3) implement the
design in the draft?

My inclination is for us to design SourceGroup v3.  This will allow the
long-term design of the draft to mature without pressure to implement
something soon.  It will also allow a mature system to be included in the next
major release, since SourceGroup has been used extensively by many users.

I have not done any design of SourceGroup v3.  This meeting will give the
people at AT&T an opportunity to be involved in this design from the
beginning.  If we agree to revise SourceGroup, here are some issues.

1. SourceGroup v2 is much simpler to use than v1.  Do the simplifications
work in practice?  Is anything more difficult in v2 that in v1?

2. Are there any other simplifications of SourceGroup that could be made?
What does current practice tell us?

3. The long-term design in the draft introduces first-class environments
to the make function.  SourceGroup still uses a single compiling environment.
The type of the make function in the draft is:
    val make :environment -> group -> environment 
Should the make function of SourceGroup v3 use first-class environments?

4. How much should we change SourceGroup?  The view of tools and dependency
analysis in the long-term design are very different from that of SourceGroup.
To adopt this view would require a complete reimplementation of separate
compilation.

5. An SML image with SourceGroup is rather large.  Is there anything we should
cut out?  Do we need to support tools other than sml, lex, and yacc?  If not
we can cut out the reading and processing of Connections files.

6. Is there anything missing from SourceGroup?  Does practice indicate
any useful additions?


Perhaps after you read the draft, you can comment on this note. ...gene


