[Openmcl-devel] Error on macro character after sharpsign colon
gb at clozure.com
Wed Jan 27 06:05:41 UTC 2010
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
>> 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
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
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
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.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel