[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

    Date: Fri, 30 Sep 88 21:35:14 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    There seem to be a number of issues regarding compilation units.
    There is this proposal and the one to limit the scope of
    proclamations.  There may be some interest in providing a license
    for block compilation (well, there's INLINE, but (among other things)
    it's not refelected in the interpreter semantics).

    Can we tie these together somehow rather than have a number of
    separate proposals, each using different mechanisms?

This is a good idea iff it can be done in the time we have left.

I have tried very hard in all my proposals not to risk getting nothing
done through an attempt to over-generalize. Nothing keeps us from
first passing a simpler issue and then running through a dependent
issue that extends the basic non-controversial functionality. I would
really prefer to do that.

If we end up not passing this issue only because someone introduces
something that makes it less palatable, I'll be quite upset.

    BTW, INCLUDE (as in "insert this file here") could be used to make
    a file compilation treat several files as a unit.

Only in a very limited way. It only works in a file, for example.
There is no analog for cases like:


How would this know to defer the warnings until the end of the file.
The effect of what you're saying is that files are the compilation unit
and you want to establish a smaller unit. I'm saying that there's some
potentially larger unit of which files are a smaller unit.

Also, INCLUDE defeats incremental compilation strategies.

Among things I'd like to do are:





         (IF (some-test (FIRST INPUT-AND-OUTPUT))

Consider a case where the result of evaluating one of the initializations
is what causes some functions to become defined that I don't want to be
warned about.