Issue: FUNCTION-TYPE (Version 5)

[Ram@C.CS.CMU.EDU]

Since this message addresses compiler semantics, I thought I'd comment
on it...

    Date: Tuesday, 23 June 1987  14:43-EDT
    From: NGALL at G.BBN.COM
    To:   Fahlman at C.CS.CMU.EDU
    Re:   Issue: FUNCTION-TYPE (Version 5)

    [...]  It is not entirely clear from your response what you
    consider to be my dubious hack.  If you mean that depending on
    implementations to dereference function-names (i.e., symbols) at
    apply time (unless declarations permit otherwise), then I must
    disagree with you.  Virtually all Lisp interpreters have this
    behavior, it is the compilers that cause inconsistent behavior.
    And since one of Common Lisp's major goals is to "impose identical
    semantics" on compiled and interpreted code, I claim that my
    examples were perfectly correct CL programs and compilers that
    don't enforce proper dereferencing are broken.

Perhaps unfortunately, it isn't possible to implement anything that
could reasonably be called a "compiler" so that it has exactly the
same semantics as traditional interpreters.  The entire purpose of a
compiler is to make use of compile-time information in order to
transform the program into a more efficient and more specific program.

In my compiler cleanup proposal, I argue that Common Lisp shouldn't
talk about the semantics of compiled v.s. interpreted code, instead it
should define "evaluation" in a way that is broad enough to encompass
both compiled and interpreted evaluation strategies.  This mostly
amounts to saying "It is an error to write a program that cannot be
compiled.", since there are few things a compiler can do that
interpreters don't.

    The ability to apply function names (and have them deferenced as
    late as possible) may have gotten into Lisp for dubious reasons,
    but it has been a very strong reason why Lisp has succeeded as a
    flexible, incremental, and rapid development environment.

This is a valid point, but it doesn't directly translate into marching
orders for Common Lisp standardization.  We should attempt to design
Common Lisp so that it doesn't preclude useful environment features,
but we are not obligated to provide them directly in the language.

I agree with you that it should be possible to force compilers to do
full function call, but the issues aren't totally clear.  For example,
the functions that are being expanded inline are presumably standard
Common Lisp functions.  It is all very well to say "NOTINLINE inhibits
inline expansion", but this capability is of little use unless you can
redefine standard functions.  [Which was discussed to death on
common-lisp a while back.]

You must always remember that when Common Lisp says that something "is
an error", implementations are not forbidden to assign meaning to that
usage.  If there is a feature that is needed to support an environment
so amazing mind-bogglingly whizzy that you can't live without it, then
everybody will want that kind of environment support, and all
"reasonable" implementations will provide it.  This in itself is not a
particularly strong argument for standardizing the *feature that
supports the environment*.  It is only when we start talking about
portable environment facilities that we become concerned.

The concept of a "reasonable" implementation is also important.
Common Lisp does not reqire implementations to be reasonable; it only
requires that programs meeting the specification run in all
implementations (subject to resource limitations and other ill-defined
vaguenesses.)   It is not a valid argument to say "X must be in Common
Lisp because I refuse to use a system that doesn't support X."  You
must demonstrate that X aids significantly in writing interesting
portable programs, rather than simply allowing you to hack in the
manner to which you have become accustomed.

  Rob