Issue: FUNCTION-TYPE (version 3)

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

In reply to: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>.

    My main problem is that it tries to clarify too many things. 

I agree with Moon that Compile can be split out of this proposal and
dealt with separately.  However, I feel that the other issues really
have to be dealt with all at once.  The issue of what constitutes the
FUNCTION type and whether function definitions have to be functions in
whatever sense we define are closely interconnected.  We'll ahve to
solve the latter issue sooner or later, so let's try to do it now.

     * I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
       the meaning and could provoke useless debate about what the difference
       might be between a function and a closure; currently CL has no such
       formal distinction.

No problem with eliminating any mention of this.  It was just a "for
instance" anyway.

     * 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.

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.

     * In item 3 of proposal, I'd say "the text of their description" to be
       completely clear. To me, the descriptions are the abstract entities
       which you've just noted don't need change.

I disagree with this use of "description", but there's no point in
arguing epistemology here.  I'll change the wording.

       Macsyma, for example, makes considerable use
       of symbols and lambda expressions in the function cell. Making sure it
       would be happy with this clause would be very non-trivial.

I don't understand this.  If your code expects to put random symbols and
lambda lists into function cells and to get them back later, unchanged,
this is not portable Common Lisp.  At least, the manual is so vague in
this area that you'd better not count on anything of this sort being
portable.  PCL was storing symbols in symbol-function cells for awhile,
but this broke lots of implementations and they finally gave up on this.

       For now, I would leave this essentially as you left APPLY, pending a
       separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
       return things which are non-functions if those objects can be coerced to
       functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
       and the value later retrieved will be the given object (not a coerced
       form of it), though obviously internally some encapsulation may want to
       go on for stock hardware to make function calling fast.

I know of several Common Lisps in which this is not the status quo.  So
either way we clarify this, it is an incompatible change for someone.  I
hate to see us take a step backwards here, just to make Macsyma more
portable than it currently is.

I agree that we should make a bit more of this issue in the "conversion
costs" section -- truth in advertising -- but I think that saying that a
function definition must be a function is an important part of the
rationalization we are trying to achieve.

Would it make life any easier for Macsyma (and other programs with this
same problem, if any exist) if we were to add a function that extracts
the lambda expression from a function if the function is uncompiled and
is not a closure (in the stronger sense mentioned above)?  In some
implementations this might be EQ or at least EQUAL to the original
Lambda, but in others it might have been macro-expanded or altered in
some way that preserves its essential behavior.  We could call the
function EXTRACT-LAMBDA-EXPRESSION or something like that.

     * At the in-person meeting at Xerox in March, I suggested that COMPILE
       should not complain if it gets an already-compiled thing, and someone
       pointed out that this could be bad because some users might be wanting
       recompilation and others might want no action. I think we should consider
       a better fix, like something that lets the user say explicitly what
       action to take if the function is already compiled, but for now I would
       leave this an error.

How about if we just adopt your earlier proposal: if the function is
already compiled, COMPILE is a no-op that returns the NAME.

     * The adoption cost does not mention STEP, TRACE, and ED. I think
       it should.

OK.

     * The benefits section should flush the reference to Lisp1, since the only
       criterion for being a Lisp-1 is that you have a unified namespace. In
       fact, this is not properly related to that and mentioning Lisp1 may
       provoke unnecessary worry. It is adequate to say it makes things more
       like Scheme.

OK.

     * I believe the conversion cost is potentially much greater than you
       have estimated unless you move items 4 & 5 to another proposal.

       The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
       important consequences to do with the inheritance of new definitions of
       BAR if it is later defined. I think that some people exploit this a lot
       and it may not always be easy to detect.

       The impact on home-grown steppers, trace and advise facilities, and other
       functions which manipulate the contents of the function cell has also been
       underplayed.

Well, as I said, such code is currently not portable because nothing in
the book unambiguously requires that symbols and lambda expressions be
put into the SYMBOL-FUNCTION cell unchanged (or that such changes be
undone upon retrieval), and because many implementations currently do
not do this.  So there's a cost either way we clarify this.  Doing it
the way you suggest tends to put the burden on implementors rather than
on the maintainers of old code, but I still think it is a step
backwards.

-- Scott