Re: Issue: FUNCTION-TYPE (Version 5)

[NGALL@G.BBN.COM]

    Date: Tue, 23 Jun 1987  10:57 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    ...
    I haven't thought this through, but I bet that one could develop a trace
    facility like the one you describe, but using anonymous stand-in
    functions that print something and then call the original function
    (which can be redefined) rather than using a symbol as a wrapper.  This
    might even be strictly portable, which your hack is not.

That's the problem.  No implementations (except perhaps Symbolics)
seem to have thought through encapsulation issues (of which tracing is
but one example).  Thus in many implementations, tracing functions
called from compiled code, even with speed 0 and safety 3 and
notinlines, does not work, or only works in some situtations.

    If the same debugging functionality can be achieved in a different way,
    I don't see the elimination of one dubious hack as a strong argument for
    keeping the status quo.

That's a big IF in my opinion, given that most implementations have so
far only provided the crudest of tracing and breaking facilities
(which all depend on apply-time deferencing of function-names).

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.

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.  If we remove this feature without alternative mechanisms
ALREADY IN PLACE, we will make Lisp debugging more primitive than
conventional language debugging.

-- Nick