[Openmcl-devel] Error on macro character after sharpsign colon
Terje Norderhaug
terje at in-progress.com
Tue Jan 26 23:00:51 PST 2010
On Jan 26, 2010, at 6:28 PM, Ron Garret wrote:
> On Jan 26, 2010, at 5:55 PM, Terje Norderhaug wrote:
>>>>
>>>> Don't let the particular situation lead you astray: This does
>>>> have to do with reading of uninterned symbols. Rather than
>>>> loading a third party module, I could just as well have written
>>>> the uninterned symbol "#:<" in my own code and expected it to
>>>> be read without error, just as "<" would be read as a symbol.
>>>
>>> If tokens were first-class entities that might be a reasonable
>>> expectation, but they aren't. If you think through the process
>>> in detail you will see that having "<" be read as a (possibly
>>> interned) symbol by a user defined reader macro function is
>>> fundamentally incompatible with "#:<" being read as an uninterned
>>> symbol.
>
>> Let's not confuse the textual representation with the object
>
> That's not the issue. The issue is that in order to read a symbol,
> the reader first has to assemble a TOKEN. By what method do you
> propose that it do so in the case that #: is followed by another
> macro character? Calling the macro function for that character
> can't work because there is no way that that function can return a
> token because tokens are not first-class data structures in Common
> Lisp. So what is it supposed to do?
It's not a practical problem. Simply commenting out the (logbitp
$cht_macbit attr) in CLZ's #'read-symbol-token makes it read #:<
without reporting an error even if the character '<' is a non-
terminating macro character.
What Gary and I have exchanged some thoughts about relates to whether
a symbol name like "<" (without the quotes) after "#:" stops having
the proper "syntax of a symbol" if you define #\< as a macro
character in the current readtable.
-- Terje Norderhaug
terje at in-progress.com
More information about the Openmcl-devel
mailing list