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

[Gary Byers]

On Tue, 26 Jan 2010, Ron Garret wrote:

>
> On Jan 26, 2010, at 5:55 PM, Terje Norderhaug wrote:
>
>> On Jan 26, 2010, at 2:59 PM, Ron Garret wrote:
>>> On Jan 26, 2010, at 2:17 PM, Terje Norderhaug wrote:
>>>
>>>> On Jan 26, 2010, at 1:58 PM, Ron Garret wrote:
>>>>> This has nothing to do with uninterned symbols.
>>>>
>>>> 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.
>>
>>
>> No, there is no "fundamental incompatibility".
>
> Yes there is.
>
>> Ceci n'est pas une pipe.
>
> Huh?  (Yes, I know of the Magritte painting to which this alludes,
> but the relevance to the matter at hand eludes me.)

A long time ago, I tried to make what I thought was a literate and
literary reference to Albert Camus' "Stranger" by explaining that
I'd introduced a horrible bug "because it was hot."

The person hearing that explanation noted that they'd read it in
French and weren't impressed.  Lisp programmers can be a tough crowd.

>
>> Let's not confuse the textual representation with the object -
>> ironically of type "symbol"... ;-)
>
>
> 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?

There are likely other reasons why calling the macro function either
can't work or wouldn't be a good idea.  I don't think that any
implementations do that or that there's any reason to think that they
would.  The #: reader-macro in the implementations whose source I
looked at do essentially what CCL does: collect a "token" by reading a
sequence of characters from the current input stream and making an
uninterned symbol out of the sequence of characters that comprise that
token.  The "collect-token" process may involve calling some internal
function that's also called by the reader.

There are at least a couple of approaches to this token-collection
process:

a) read characters and process escape characters until a delimiter
    (whitespace, terminating macro, EOF) is encountered.

b) essentially the same, but insist that the first character is
    a constituent or escape character (and not a non-terminating
    macro.)

Some implementations follow (a); others (including CCL) follow (b).
I haven't heard any argument in favor of (a) that doesn't seem to
be based on a misunderstanding of what's happening here.

We can't - in the standard readtable - refer to a symbol whose
name's first character is a non-constituent without escaping that
character. In the standard readtable, ABC is a symbol name and
#ABC is an incorrect use of the #A (array reader) reader macro.

If #: expects a symbol name to follow on its input stream, then
rejecting

? '#:#abc

on the grounds that #ABC isn't a token (something with "symbol syntax")
seems preferable to quietly accepting that non-token and treating it
as a symbol name.

If I understand his argument correctly, Terje seems to be saying that
he finds it unintuitive that #:!abc is rejected when his definition of
a reader macro on #\! would produce a symbol.  I think that this is
based on the assumption that - like many other reader macros - #:
calls READ or somehow behaves as if it did.  That wouldn't be a correct
assumption, though I think that it may be necessary to read the spec
carefully (and read between the lines a bit) to convince yourself of
that.  The phrase "the symbol name must have the syntax of a symbol
and must not contain package qualifiers" in the description of #:
only makes sense if we interpret <<symbol-name>> in that description
as "hopefully valid token following the #: on the input stream" rather
than "expression to be READ recursively, invoking macros as usual and
hopefully producing a SYMBOL whose name is used by #:".

If this assumption isn't the basis of Terje's arguments, then I have
even less of an understanding of them than I do now.

>
> rg
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
p