[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: WITH-COMPILATION-UNIT (Version 1)
- To: email@example.com
- Subject: Re: Issue: WITH-COMPILATION-UNIT (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 30 Sep 88 12:34 EDT
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@sail.stanford.edu
- In-reply-to: <8809300128.AA07746@defun.utah.edu>
Date: Thu, 29 Sep 88 19:28:25 MDT
From: firstname.lastname@example.org (Sandra J Loosemore)
This issue strikes me as a special case of "block compilation" across
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.