Re: Issue: WITH-COMPILATION-UNIT (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 29 Sep 88 19:28:25 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    This issue strikes me as a special case of "block compilation" across
    multiple files.

This issue has nothing to do with block-compilation, although we could
extend the syntax to permit an options list before the body so that 
implementations could provide options like that if they wanted.

    As an alternative to introducing a new construct, we just extend
    COMPILE-FILE to take a list of files (instead of a single pathname)
    as an argument?

No. The example is oversimplified. In even the most simple real cases
you need to do things like intertwine compiling and loading so
it's not really an issue of COMPILE-FILE. It doesn't take much work
to come up with situations where various evaluations or other things
want to come between the file compilations. [That happens in the Symbolics
source control tool, for example.]

Further, changing COMPILE-FILE wouldn't address the same problem in
in-core compilation (the COMPILE function).

    A specific comment about the wording of the proposal: the description
    of the "actions" that are performed at the end of compilation is much
    too vague.  For instance, my implementation of COMPILE-FILE writes out
    out the binary file and closes its stream at the end of compilation. :-)

Well, it's intended to be liberally interpretable by implementations... but
I wouldn't want implementations to feel accidentally constrained in strange
ways. I'll see about tightening it up a bit.

    In general, the issue as presented does not strike me as being
    particularly critical.  I don't know anybody who gets really upset
    about the compiler printing out messages at various stages along the
    way, or expects to see exactly the same messages from every compiler.
    On the other hand, if the proposal were reworked to address more general
    block compilation issues, I think it would be worthwhile to pursue.

I personally think this is a major deal.  Porting Macsyma was made
massively more difficult by the millions of undefined function warnings
that we got at the end of compiling each of the nearly 200 files. Not
all files get used in every implementation, so there were legitimate
undefined function warnings and it was not possible to just ignore every
such warning. Speaking from experience in having had to stare at
zillions of pages of compiler warnings, I know this facility would have
saved me tons of time -- as I recall, several vendors who didn't offer
the capability expressed a willingness to provide it if only they knew
how the interface should look.