#

## Issue COMPILE-ARGUMENT-PROBLEMS-AGAIN Writeup

    Issue:		COMPILE-ARGUMENT-PROBLEMS-AGAIN
    References:	COMPILE-ARGUMENT-PROBLEMS, draft 10.156 p.3-52
    Category:	CHANGE
    Edit History:   9-Dec-91, Version 1, by Moon
    Status:         Passed 10-Dec-91; 11-0 on part 1, 9-1-1 on part 2

    Problem Description:

      Cleanup COMPILE-ARGUMENT-PROBLEMS:CLARIFY created a couple of problems:

      (1) It says "The consequences of calling COMPILE on a function that is already
      compiled are unspecified" but the spec doesn't provide any way to create a
      function that is guaranteed not to be compiled already.  In fact the example
      at the top of page 3-52 is invalid because of this.

      (2) It says the consequences are undefined "if the function to be compiled was
      defined interpretively in a non-null lexical environment", but a non-null
      lexical environment doesn't imply a closure. It might just have declarations in
      it. The original motivation was "Many implementations cannot correctly compile
      functions that are defined interpretively in a non-null lexical environment,
      because the compiler and interpreter use different representations for
      closures."

    Proposal (COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX):

      (1) Remove the quoted text and specify that COMPILE either returns the function
      it is given or returns an equivalent function, but in any case returns a
      COMPILED-FUNCTION.

      (2) Replace the quoted text with "if the lexical environment surrounding the
      function to be compiled contains any bindings other than macros, symbol macros,
      or declarations".

    Rationale:

      (1) Given a function that is already compiled, COMPILE can simply return it.

      (2) Bindings that minimal compilation would remove shouldn't prevent COMPILE
      from working, since no closure would be required.

    Cost to implementors:

      (1) Trivial.
      (2) Might require some work, depending on what the interpreter does with
      macros in the lexical environment of an interpreted function.

    Cost to users:

      None.  This is an upward-compatible change.

    Benefits:

      (1) Users don't have to insert extra COMPILED-FUNCTION-P checks.
      (2) Make the language less restrictive.

    Discussion:

      Parts 1 and 2 should be voted separately.

Copyright 1996-2001, Xanalys Inc. All rights reserved.