[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question about readtable null arguments
I just noticed a certain ambiguity (What else is new? :-) in CLtL that
I would like to get clarified.
In 22.1.5, p 361, the definitions of `copy-readtable' and of
`set-syntax-from-char' establish a convention that a NIL readtable
argument that is used as source for a copy, refers to the "standard
Common Lisp readtable". (This is slightly irregular, as in other
contexts an omitted argument is the same as a null argument, but I
No such guarantee is given for other readtable arguments that happen
to be simultaneously optional and from-. There are (at least) two
other functions where this convention would be useful:
get-[dispatch-]macro-character both take an optional readtable from
which they copy some information. Both default to *readtable*. But
nothing is said about explicitly giving them NIL.
In spite of not giving an explicit guarantee (OR DID I MISS IT?),
Steele seems to believe that the same convention applies. In p 378,
he uses (get-macro-character #\) nil) with the comment "...Giving }
the same definition as the standard definition of the character )
has...", which makes me think he expects the "NIL means standard"
convention to apply.
I checked three implementations. Two of them (Symbolics and Xerox)
seem to take the benign interpretation, making Steele's example of p
378 work. KCl, on the other hand, sent me to the debugger:
>(get-macro-character #\) nil)
Error: NIL is not of type READTABLE.
Error signalled by GET-MACRO-CHARACTER.
Broken at GET-MACRO-CHARACTER. Type :H for Help.
So, I'd appreciate hearing from the Lisp community, especially from
1- Is there in CLtL an explicit statement of the convention that
optional readtable arguments, in from- usage, supplied with an
explicit NIL, should mean the standard readtable?
2- If not, is it nonetheless common to take that interpretation?
In your version of Common Lisp, (get-macro-character #\) nil)
2.a. Produces the macro function (perhaps nil) associated
with ) in the standard readtable.
2.b. Errors out.
2.c. Does something else (like checking the current readtable).
3- If your implementation takes the benign approach, what standard
functions have been implemented to show this behavior? (I guess
the get-... ones are the only ones, I'd like to know if I missed
I will summarize the responses. Thanks,
PS. I have patches (trivial) to make KCl behave nicely to the
example in p. 378. If you are interested, I can send them to you, or
post them if there is any interest.