Issue: EVAL-DEFEATS-LINKER

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 12 Jun 87 22:55 PDT
    From: Masinter.pa@Xerox.COM

    Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):

I don't think this is a good choice of name, because only the third paragraph
of the proposal has anything to do with EVAL.  EVAL-DEFEATS-LINKER:CLOSED-SYSTEM
would be a better name, and EVAL-DEFEATS-LINKER:REMOVE-FUNCTION-COERCION would
be even better if the readtable part is dropped as I suggest below.  This is
nit-picking, of course.

    Change the definition of the function type to exclude symbols and lists.
    Change the definition of FUNCTIONP to be false of symbols and lists.

The above two lines are redundant with the FUNCTION-TYPE proposal.  I guess
that means that this proposal has FUNCTION-TYPE as a prerecquisite.

    Change the definitions of APPLY and FUNCALL so it is an error to pass
    them a symbol or a list as their first argument.

    Functions such as MAPCAR that are defined by reference to the concept of
    function or by reference to APPLY and FUNCALL would be affected by these
    changes as well, but it would not be necessary to change their
    written specification.

This is the first cogent argument I have seen for why APPLY and FUNCALL should
not coerce names of functions to functions.  I'm glad to see the discussion
getting real.

One way to address the conflict between compatibility with existing
programs and the proposed automated subsetting of Common Lisp by observing
what features are manifestly used by a given program, would be to note the
use of the phrase "is an error".  This allows all existing implementations
to agree on an extension to Common Lisp to support coercion of function
names to functions, i.e. to agree to continue to do what they do now, while
not requiring future implementations to support that.  Programs that exploit
that feature would no longer be portable in law, but would remain portable
in practice, which seems like a desirable state of affairs.

These existing implementations could also agree on a switch that disables
the extension, to facilitate portability to implementations that lack the
extension.  I have to caution, however, that implementing such switches as
dynamic variables generally does not work in implementations where the
operating system is written in Lisp; we have some distasteful experience
with that in the areas of case-sensitivity in string comparison and
NIL-sensitivity in CAR and CDR.  Implementing the switch in a lexical way,
for instance by providing a package containing alternate versions of
FUNCALL, APPLY, and every CL function that calls FUNCALL or APPLY, would
avoid this problem.  There may be other techniques that are more
appropriate than switches.  Unfortunately reliance on coercion from
function names to functions is not, in general, detectable at compile time.
If it was detectable at compile time, this whole linker issue would not
have arisen.

    Remove the #. and #, dispatching macro characters from the standard reader
    syntax.  Require the interpreter, compiler, and interactive loader to use
    a reader syntax that has been extended by adding the #. and #, dispatching
    macro characters.

I see no reason to include this third part in the proposal.  Common Lisp already
provides ways to make customized readtables, and applications that want to run
in stripped-down Lisps can use those mechanisms to make readtables that don't
contain #. and #, and can inform their linker that they are using those mechanisms.
The proposal should mention the existence of the #. loophole, of course.
Isn't #S a bit of a loophole, also, although not quite as bad?

I have thought of one additional loophole; perhaps the best way to describe it
is with an example.

(defvar *funcall-loophole*)
(deftype funcall ()
  `(satisfies ,*funcall-loophole*))
(defun funcall-the-old-way (symbol argument)
  (let ((*funcall-loophole* symbol))
    (typep argument 'funcall)))
(funcall-the-old-way '1+ 5) => 6

Perhaps a linker can be written to detect the presence of DEFTYPEs complex
enough that they could be this loophole.  I could have written this without
using any special variables, and without using DEFTYPE; I just put those in
to make it look more complicated and thus harder to detect at compile time.
The key point here is that the SATISFIES type-specifier is defined to call
SYMBOL-FUNCTION.  I don't think we want to change that.