summary of issues

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

In case any of you have gotten buried under all the mail that's been
flying back and forth within the past week or so, here is a revised
summary of our pending issues.  I hope I have not misrepresented or
totally forgotten about anybody's comments.

-Sandra



X3J13 Compiler Cleanup Status as of 28 Sep 1988:
================================================


Old issues (distributed for comments at the June meeting), ready to be
voted upon:

    COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
	What are the compile-time side-effects of the various defining
	macros?

        Comments received after the proposal was distributed again for
        a vote at the October meeting:

        * Gray raised more concerns about handling of DEFCONSTANT.
          He has volunteered to write this up as a separate issue.

	* Pitman raised numerous objections to the wording of the
	    proposal.
          We expect to work with the editorial committee to resolve
	    this.


    EVAL-WHEN-NON-TOP-LEVEL
	What does EVAL-WHEN mean when it does not appear as a top-level
	form?

        Comments received after the proposal was distributed again for
        a vote at the October meeting:

        * Benson pointed out that the sample implementation for
            EVAL-WHEN won't work if the EVAL-WHEN macro is run 
	    interpretively; instead of using the special variable
	    *COMPILING-P*, the information should be stored in the 
            environment instead.
          See issue COMPILE-FILE-ENVIRONMENT below.  We can work with
	    the editorial committee on the wording in the standard.

	* What does EVAL-WHEN do in a compiled-only implementation?
	  This issue needs to be addressed but I think it is largely
	    orthogonal to the issue of where EVAL-WHEN can appear.  I
	    think it could be handled by a separate proposal.

        * Pitman raised objections to the wording of the proposal.
	  We can address this with the help of the editorial committee.

	* Pitman and Kempf raised general objections to allowing
	    EVAL-WHEN in non-top-level places.  



    DEFINING-MACROS-NON-TOP-LEVEL
	Can defining macros such as DEFUN appear in non-top-level
	locations?

        This issue provoked the only comments that were received since
	the last meeting:

	* The wording of section 4 was garbled.
	  This has been fixed in the latest version of the proposal.

	* Many implementations do not allow a lexical environment to be
	    shared between compiled and interpreted functions.
	  A new issue, COMPILE-ARGUMENT-PROBLEMS, has been written up
	    to deal with this problem.

	* Forms within a COMPILER-LET and the expansion of a top-level
	    macro should also be considered top-level.
	  This has been fixed.

        Comments received after the proposal was distributed again for
        a vote at the October meeting:

	* The motivation for Section 5 of the proposal was unclear to
	    some people.
	  This section was added to allow compilers to perform certain
	    kinds of source-to-source transformations that rearrange
	    subforms.  We will provide some examples to the editorial
	    committee.

	* Pitman says that it is inconsistent for (DEFUN FOO ...
	    (DEFMACRO BAR ...)) to make the definition of BAR available
	    immediately at compile time, but only after FOO is called
	    at runtime.
	  That's life.  People expect macro definitions made with DEFMACRO
	    to be available at compile time; it would be just as inconsistent
	    to make them available some times but not others.

	* Pitman says that this proposal would encourage people to try
	    using DEFUNs nested inside of other DEFUNs, thinking that the
	    nested DEFUNs will create local functions (as in Scheme), and
	    end up getting very confused.  He would prefer to restrict
	    defining macros to appearing only at top-level.
	  We will work with the editorial committee to make sure that the
	    standards document emphasizes that DEFUN always establishes
	    a global function definition, no matter where it appears.



New issues that are ready to be voted upon:

    COMPILE-ARGUMENT-PROBLEMS
	What functions can be compiled with COMPILE?

	* Pitman thinks it should not be an error to try to compile a
	    function that is already compiled, particularly since an
	    implementation might compile all functions.
	  We need to revise the error terminology anyway to make it
	    conform to what the editorial committee is using.  Would
	    it be acceptable to state that the behavior is "unspecified"
            (unpredictable but harmless)?


    COMPILE-FILE-PACKAGE
	COMPILE-FILE should rebind *PACKAGE*.

	* Pitman supports this proposal but would like to change the 
	    wording to state that *PACKAGE* is rebound to its current
	    value.


    OPTIMIZE-DEBUG-INFO
	What OPTIMIZE quality controls debuggability of compiled code?

	* Pitman suggests leaving out references to absolute magnitudes
	    of OPTIMIZE qualities, pending discussion of whether it is
	    absolute magnitude or relative value compared to other qualities
	    that is significant.
	  This issue has been on our list but no one has volunteered to
	    write a proposal on it yet.


    PROCLAIM-INLINE-WHERE
	INLINE proclamations should be placed before the corresponding
	DEFUN.

	* Pitman expressed support for this proposal.


Issues in draft form (comments requested):

    COMPILE-ENVIRONMENT-CONSISTENCY (Loosemore)
	What things can the compiler safely "wire in" to code being
	compiled?

        * Benson suggests adding a condition to explicitly allow the
	    compiler to make assumptions based on FTYPE declarations.
	  This is a good idea, but I'm not aware if we've ever resolved
	    whether an FTYPE declaration must match exactly the definition
	    of the function, or whether it only needs to match calls to
	    the function within the scope of the declaration.  For example,
	    is it legal to declare + as taking two FIXNUM arguments?
	

    PROCLAIM-ETC-IN-COMPILE-FILE (Gray)
	Add PROCLAIM, REQUIRE to list of N random package functions that
	COMPILE-FILE must eval at compile time.

	If DEFPACKAGE is accepted, we may want to take a different
	approach on this issue.  How would people feel about
	eliminating the special behavior of these functions entirely?


    ALLOW-LOCAL-INLINE  (Gray)
        Define a LOCAL-INLINE declaration to control inlining of
	functions.

        Tabled until PROCLAIM-INLINE-WHERE is resolved.


    COMPILE-FILE-ENVIRONMENT (Moon)
	Clarify that environment objects captured with &ENVIRONMENT
	contain information about whether the macro is being expanded
	in the context of the compiler or interpreter.

	Apparently CLOS also needs to store some additional information
	in environment objects.  How about somebody writing up a
	proposal that takes care of that as well?


    COMPILER-LET-CONFUSION (Loosemore)
	The description of COMPILER-LET in CLtL is confusing, and doesn't
	make sense for implementations that do not perform macroexpansion
	in parallel with evaluation in the interpreter.

	Proposal is in the draft stage.

	    
    DEFINE-OPTIMIZER (Pitman)
	Provide a way to define and access "compiler macros".  

	Proposal is in the draft stage.



Issues in progress (no proposals ready yet):

    LOAD-TIME-EVAL (Loosemore)
        What does #, mean?  Where can it appear?

	Lots of discussion but no consensus on this issue yet.

    
    COMPILED-CONSTANTS (Perdue)
        Are quoted constants in compiled code read-only?  Must the compiler
        handle circular constants?  Preserve nonprintable aspects of constant
        data?

    COMPILER-DIAGNOSTICS (Need volunteer)
	Are warnings issued by the compiler really warnings?

	We might define a separate condition for compiler diagnostics.
-------