[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