Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4

[masinter.pa@Xerox.COM]

I think the previous sentiment was more strongly toward removing
COMPILED-FUNCTION rather than tightening its definition. However, in the
heat of the FUNCTION-TYPE discussion, this seemed to be a controversial
backward incompatibility (why not just leave it in, but leave it
unspecified?) 

I've extracted some quotes about COMPILED-FUNCTION from the CL-CLEANUP
discussion on FUNCTION-TYPE. Of course, these are taken out of context... 

Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 02 MAR 87 21:29:49 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar
87  21:27:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82Date: Tue, 3
Mar 87 00:26 EST
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Mar 87 00:26 EST

It might be wise to add LEXICAL-CLOSURE and INTERPRETED-FUNCTION data
types, to go along with the COMPILED-FUNCTION type that already exists.
These three would be disjoint subtypes of FUNCTION, but not necessarily
an exhaustive partition.  There might be other ways to slice the space
of types, since it's not so clear what a function not inside a closure
is good for.  Alternatively we could flush COMPILED-FUNCTION and say
that the subtypes of FUNCTION are all implementation-dependent.  But I
think having COMPILED-FUNCTION without the others is weird.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 21:56:23 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87
21:53:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 00:53:51-EST
Date: Mon, 9 Mar 87 00:53 EST
 From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.  
- - - - - - - - -
Return-Path: <RPG@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 23:54:05 PST
Date: 08 Mar 87 23:51 PST
 From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

Possibly these should not be required to be pairwise disjoint (?).

I think we shouldn't presume that all implementations implement 
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 09 MAR 87 08:07:46 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87
08:01:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 10:57:49-EST
Date: Mon, 9 Mar 87 10:57 EST
 From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

Well, these make sense only in systems that do support both compiled and
interpreted code.  In compiler-only or interpreter-only systems, I guess
the best move would be to say that every function is a member of both of
these subtypes: it is both a fast function and a slow function.

Now you're the one who is letting the user see internal stuff that is
none of his concern.  All of these functions are closures, in that they
no longer have any free variables waiting to be closed.  In some cases,
there may have been none in the first place, and implementors may want
to use some efficient internal form in such cases, but is there any
reason the user needs to know that?  A confusing concept that does him
no good (I think).
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 10 MAR 87 07:54:56 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar
87  07:48:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89098; Tue
10-Mar-87 01:57:50 EST
Date: Tue, 10 Mar 87 01:57 EST
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

... I vacillate between
saying that all of the subtypes of FUNCTION are implementation-dependent
and shouldn't be standardized (thus COMPILED-FUNCTION should be
removed), and saying that programs might want to know this information,
so all the plausible subtypes should have standard names, even if they
aren't distinct in some implementations.  The only thing I feel strongly
and consistently about is that COMPILED-FUNCTION should not be the only
standardized subtype of FUNCTION; it should either acquire some siblings
or go away.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 MAY 87 00:13:57 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May
87  00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
 From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

 * It seems to me that we might as well go ahead and create types
   INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
   the FUNCTION type and the COMPILED-FUNCTION-P predicate already
implements
   this distinction. Perhaps eventually COMPILED-FUNCTION-P could be
flushed.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 17 MAY 87 19:32:45 PDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87
19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 87 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU

One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P.  That's what I proposed in version 3.  The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example.  Then there's the question of whether closures are, or can be,
a separate subtype.  In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment.  However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.

In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
- - - - - - - - -
Date: 29 May 87 21:18 PDT
Subject: Issue: FUNCTION-TYPE (version 4)
 From: Masinter.pa

Proposal FUNCTION-TYPE:REDEFINE

...
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION.  Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 01 JUN 87 21:23:10 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun
87  21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue
2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
 From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    This proposal removes the predicate
    COMPILED-FUNCTION-P from the standard language.

If it also removes the COMPILED-FUNCTION type-specifier, say so here.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 JUL 87 12:58:35 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87  12:54:07
PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
 From: Masinter.pa

... My notes [from X3J13 meeting] include ...  that we be more consistent
about justifying removing COMPILED-FUNCTION-P (i.e., why bother?) ...
- - - - - - - - -
Date: 23 Oct 87 11:51 PDT
 From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (Version 6)

here is a revised version... I left COMPILED-FUNCTION and
COMPILED-FUNCTION-P as subtypes of FUNCTION.
...
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
...
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations are
free to define other subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.  
- - - - - - - - -
(wording preserved through several iterations)
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanupâ??.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 16 FEB 88 09:41:39 PST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88
09:39:23 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23751; Tue, 16 Feb 88 10:39:08 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA25191; Tue, 16 Feb 88 10:39:04 MST
 From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8802161739.AA25191@orion.utah.edu>
Date: Tue, 16 Feb 88 10:39:02 MST

Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION.  Does this imply that it must be a *proper*
subtype?  For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments).  Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all.  I think this needs to be clarified.
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanupâ??.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 19 FEB 88 14:37:22 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88  14:34:11
PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST
Date: 19 Feb 88 14:17 PST
 From: Masinter.pa
I intended not to require that it not be a "proper" subtype in the sense
that
there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP.

This can be clarified. 
- - - - - - - - -
Return-Path: <edsel!jonl@labrea.Stanford.EDU>
Received: from labrea.Stanford.EDU by Xerox.COM ; 24 FEB 88 10:14:38 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:20 PST
Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88
10:03:43 PST
Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST
Date: Wed, 24 Feb 88 10:09:26 PST
 From: Jon L White <edsel!jonl@labrea.Stanford.EDU>

Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled.  It only takes a bit in a header word.  If an
implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP  doesn't sound like much of a loss.  

But most implementations in fact do support an interpreter -- which 
typically runs code at anywhere from 30 to 600 times slower than when
compiled.  Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
	(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter
closures.
- - - - - - - - -
Date:  4 Sep 88 13:39 PDT
 From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO

This is the final version of the FUNCTION-TYPE issue, as passed at the June
88 X3J13 meeting; that is, it incorporates the amendments that were adopted
before the issue was adopted.

...
    1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
        Implementations are free to define other subtypes of FUNCTION.