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

[Gary Byers]

I don't know enough about it to be sure, but Tobias Rittweiler's
NAMED-READTABLES package

<http://common-lisp.net/project/editor-hints/darcs/named-readtables/doc/named-readtables.html>

may offer features that try to make some of this more manageable.

(I'd agree that it's non-trivial to solve the general problem, but
practical solutions that make readtable extensions more manageable
could certainly be useful.)




On Tue, 26 Jan 2010, Ron Garret wrote:

> 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
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>