CLHS: Issue WITH-COMPILATION-UNIT Writeup

#

## Issue WITH-COMPILATION-UNIT Writeup

    Forum:	      Compiler
    Issue:        WITH-COMPILATION-UNIT
    References:   COMPILE (p438), COMPILE-FILE (p439)
    Category:     ADDITION
    Edit history: 29-Sep-88, Version 1 by Pitman
    	      10-Mar-89, Version 2 by Pitman (merge comments)
    	      13-Mar-89, Version 3 by Loosemore (update discussion)
    	      10-Apr-89, Version 4 by Pitman (wording change per X3J13)
    Status:	      Ready for release

    Problem Description:

      Some actions done by the compiler (and particularly the file compiler)
      are typically deferred until the "very end" of compilation.  For example,
      some compilers complain about "functions seen but not defined".

      Unfortunately, since COMPILE-FILE is the largest unit of granularity,
      and since systems often extend over more than one file, it often happens
      that the compiler needlessly complains at the end of compiling one file
      about the absence of functions defined in the next file.

    Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):

      Add the following new macro:

       WITH-COMPILATION-UNIT options &BODY forms			[Macro]

       Executes forms from left to right. Within the dynamic context
       of this form, warnings deferred by the compiler until "the end of
       compilation" will be deferred until the end of the outermost call
       to WITH-COMPILATION-UNIT. The result(s) are the same as that of
       the last of the FORMS (or NIL if FORMS is null).

       OPTIONS is a keyword/value list, where only the values are
       evaluated. The set of keywords permitted may be extended by the
       implementation, but the only keyword defined by this standard is:

         :OVERRIDE boolean

           The default is NIL. If nested dynamically only the outer call
           to WITH-COMPILATION-UNIT has any effect unless BOOLEAN is T,
           in which case warnings are deferred only to the end of the
           innermost call.

      It follows that the functions COMPILE and COMPILE-FILE should
      provide the effect of (WITH-COMPILATION-UNIT (:OVERRIDE NIL) ...)
      around their code.

      Any implementation-dependent extensions may only be provided
      as the result of an explicit programmer request by use of
      an implementation-dependent keyword.  Implementations are forbidden
      from attaching additional meaning to a conforming use of this
      macro.

      Note also that not all warnings are deferred. In some implementations,
      it may be that none are deferred. This proposal only creates an
      interface to the capability where it exists, it does not require the
      creation of the capability. An implementation which does not do
      deferred warnings may correctly implement this as expanding into PROGN.

    Test Case:

      (DEFUN COMPILE-FILES (&REST FILES)
        (WITH-COMPILATION-UNIT ()
          (MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))

      (COMPILE-FILES "A" "B" "C")

      processes deferred warnings only after compiling all of A, B, and C.

    Rationale:

      This will make the development of portable system-construction tools
      considerably more convenient.

    Current Practice:

      Lucid has a very similar facility, called WITH-DEFERRED-WARNINGS.

      TI Explorer and Symbolics Genera have a similar facility, which they
      call COMPILER-WARNING-CONTEXT-BIND.

    Cost to Implementors:

      In implementations which have no deferred warnings, there is no cost.

      In implementations which have deferred warnings, the cost is probably
      fairly small -- usually just a matter of writing interfacing the
      proposed macro to an existing one.

    Cost to Users:

      None. This is a compatible addition.

    Cost of Non-Adoption:

      Portable system-construction tools would continue to print lots of
      spurious warnings because they would have no way to tell the system
      that a set of files was working together.

    Benefits:

      The cost of non-adoption is avoided.

    Aesthetics:

      The ability to create a compilation unit other than a file is important.

    Discussion:

      Pitman and Benson support this addition.

      One could imagine adding more options at a later date.

      It was the opinion of the compiler committee that there was room for
      expansion here to address issues like bounding the scope of global
      proclamations, sharing compile-time environments across files, etc.
      However, insufficient work was done on this to justify putting such
      a thing into the standard. The only clear need we have at this time
      was to defer warnings, but we chose a general name like
      WITH-COMPILATION-UNIT rather than a specific name like Lucid's
      WITH-DEFERRED-WARNINGS in order to encourage implementations to
      experiment with other kinds of options under implementation-specific
      keywords. Perhaps by the time of the next standard there will be
      sufficient understanding of this area to warrant further elaboration
      of this primitive.

      Kim Barrett says:

        I strongly oppose the behavior you proposed for compile and
        compile-file.  It is my belief that whether to override or not must be
        controlled through an argument to the compile functions, with the
        default being to override.  Otherwise, all existing code which makes
        use of the compile functions must be modified to protect itself by
        wrapping a (with-compilation-unit (:override t) ...) around the calls
        to the compiler.

        Consider a stream system built on an object system which will compose
        and compile functions on the fly on an as needed basis.  It would be
        very strange for the functions so generated while doing file io for
        the user's compile-file to have any relationship with said
        compile-file.

        I agree with your position that implementation-dependent extensions
        must be explicitly requested.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.