[Openmcl-devel] Error on macro character after sharpsign colon

[Ron Garret]

Ah.  Well, that's just a specific instance of a much more general problem, which is that *readtable* is global, and if you muck with it you can break code that tacitly assumes that the readtable wasn't mucked with.  This has nothing to do with uninterned symbols.

Here's a much more interesting example of the same problem: in my personal library I have synonyms for FIRST, SECOND, THIRD called 1ST, 2ND, 3RD etc.  Then one day I loaded Ralf Moeller's measures system, which lets you do things like this:

? (* 23.6kg 9.8m/s2)
0.23128kN

which is very spiffy, but has the following unfortunate side-effect:

? (1st '(1 2 3))
> Error: Undefined unit st in unit specification: st.

Sorting this out is a non-trivial design problem.

rg

On Jan 26, 2010, at 1:36 PM, Terje Norderhaug wrote:

> On Jan 26, 2010, at 11:58 AM, Ron Garret wrote:
>> Just out of curiosity, why would anyone ever want to read an  
>> uninterned symbol whose name began with a macro character?
> 
> A better question is "why not?", particularly when it comes to user- 
> defined macro characters rather than dispatch characters in the  
> Common Lisp standard syntax.
> 
> The case I have encountered involves my long time use of the special  
> sequence "<![[" to signify the beginning of markup inlined in lisp  
> code, adhering to the syntax of an SGML/XML "marked section". I am  
> mostly using it to inline XSL transformations as a little language  
> within lisp code.
> 
> Loading a third party module surprisingly failed when reading an  
> uninterned symbol that started with "#:<" even if the string after  
> the sharpsign colon would have been read as a symbol.
> 
>> On Jan 26, 2010, at 11:38 AM, Terje Norderhaug wrote:
>> 
>>> Regarding CLZ not allowing a user defined macro character after the
>>> #: of an uninterned symbol:
>>> 
>>> On Jan 25, 2010, at 1:56 PM, Gary Byers wrote:
>>>> The spec says:
>>>> 
>>>> "A non-terminating macro character is treated as a constituent when
>>>> it appears in the middle of an extended token being accumulated."
>>>> 
>>>> (An initial macro character would cause the function associated with
>>>> that character to be called in the standard reader algorithm
>>>> describted
>>>> in section 2.2; a token that begins with an unescaped macro  
>>>> character
>>>> would not have "the syntax of a symbol.")
>>>> 
>>>> The spec says that the <<symbol-name>> following #:"must have the
>>>> syntax of a symbol"; I think that I'd rather have the reader  
>>>> complain
>>>> when this is violated than quietly accept invalid/undefined syntax.
>>> 
>>> Wouldn't it be reasonable to understand "syntax of a symbol" in the
>>> spec to refer to the Standard Syntax rather than the user extended
>>> syntax? If so, the reader could complain when the symbol name
>>> following #: starts with a character in the Standard Readtable yet
>>> allow custom macro characters in the Current Readtable.
>>> 
>>> Not allowing a user defined macro character after the #: of an
>>> uninterned symbol discourages even careful use of custom reader
>>> macros. An alternative resolution could be to signal a *continuable*
>>> error when encountering an uninterned symbol that starts with a macro
>>> character, giving the developer the final say.
>>> 
>>>> On Mon, 25 Jan 2010, Terje Norderhaug wrote:
>>>> 
>>>>> CLZ fails to read an uninterned symbol if the sharpsign colon is
>>>>> followed by a macro character. Is this a bug or correct behavior? I
>>>>> got no wiser by reading the hyperspec, but presume it's in there
>>>>> somewhere:
>>>>> 
>>>>>  http://www.lispworks.com/documentation/lw50/CLHS/Body/02_b.htm
>>>>> 
>>>>> Replicate by evaluating the following:
>>>>> 
>>>>> (defun symbol-reader (stream char)
>>>>>  (declare (ignore char))
>>>>>  (read stream t nil t))
>>>>> 
>>>>> (set-macro-character #\! #'symbol-reader T)
>>>>> 
>>>>> '!abc
>>>>> => ABC
>>>>> 
>>>>> '#:!abc
>>>>> => Reader error: Illegal symbol syntax.
>>>>> 
>>>>> Backtrace leads to #'read-symbol-token in the l1-reader.
>>>>> 
>>>>> LispWorks (5.0 Personal) reads '#:!abc without reporting an error.
>>>>> Which implementation is right?
>>>>> 
>>>>> -- Terje Norderhaug
>>>>> terje at in-progress.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Openmcl-devel mailing list
>>>>> Openmcl-devel at clozure.com
>>>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>>> 
>>>>> 
>>> 
>>> -- Terje Norderhaug
>>>  terje at in-progress.com
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
> 
> -- Terje Norderhaug
>   terje at in-progress.com
> 
> 
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel