[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Special Form Question
- To: shebs%utah-orion@UTAH-CS.ARPA
- Subject: Re: Special Form Question
- From: NGALL@BBNG.ARPA
- Date: Fri, 13 Dec 1985 14:04:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <8512130236.AA20979@utah-orion.ARPA>
- Sender: NGALL@BBNG.ARPA
Date: Thu, 12 Dec 85 19:36:38 MST
From: firstname.lastname@example.org (Stanley Shebs)
Subject: Special Form Question
This may seem like an exceptionally stupid question, but what should
the following do?
(setf (symbol-function 'foo) (symbol-function 'quote))
(foo (a b c))
While CLtL prohibits defining new special forms, it's not clear
that this use is defining a "new" form. Also, symbol-function on
special forms is allowed to return something (whose exact nature is
carefully left vague) which presumably can be used elsewhere. The
whole thing sure looks like a nod to implementations which still have
nasty fexprs :-), and for which the above trick would be valid.
Am I right? Or is it OK for symbol-function of a special form to
signal an error?
It is clearly NOT OK for (symbol-function 'quote) to signal an error, pg. 90.
It is not clear (in CLtL) whether
(setf (symbol-function 'foo)
is an error ("The set of special forms is fixed in CL." pg. 57);
must "work" (Note that there is no restriction on the "specified definition"
that may be assigned to the symbol-function gen. var., pg. 90;
is left undefined (Note that vagueness of what symbol-function of a special
form returns and what special-form-p returns (and what can be done with them).
I vote for "is an error" for the simple reason that portable code analyzers
(incl. compilers) count on the fact that they must have special-purpose
code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on
pg. 57). If we break this restriction, portable code ananlyzers would become
much more complicated (if not impossible without further CLtL revisions).
Besides, why would anyone need to do such a thing? Remember macros?...