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

[Tobias C. Rittweiler]

Gary Byers <gb at clozure.com> writes:

> 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.

SBCL behaves like a), and I'd defend that as the "better" choice -- of
course, I cannot give an official position statement, it's my personal
opinion:


   2.4.8.5 Sharpsign Colon says

  "The symbol-name must have the syntax of a symbol with no package
   prefix."


The CLHS talks about "syntax of a symbol" only to differentiate tokens
between numbers, potential numbers, and symbols. See for example:


  2.3.1 Numbers as Tokens

  "When a token is read, it is interpreted as a number or symbol. The
   token is interpreted as a number if it satisfies the syntax for
   numbers specified in the next figure."

or

  2.2 Reader Algorithm, 2nd §.

  "When dealing with tokens, the reader's basic function is to
   distinguish representations of symbols from those of numbers. When a
   token is accumulated, it is assumed to represent a number if it
   satisfies the syntax for numbers [...]. If it does not represent a
   number, it is then assumed to be a potential number if it satisfies
   the rules governing the syntax for a potential number. If a valid
   token is neither a representation of a number nor a potential number,
   it represents a symbol."


Now I think that 2.4.8.5 -- when it talks about "must have the syntax of
a symbol" -- that this statement can only imply that the thing after #:
is interpreted as a token as an a priori decision.

This means now, that #: must perform step 8 in the Reader Algorithm
(2.2) which is the only place in the standard that specifies how tokens
are actually read.

Following step 8, a non-terminating macro character is just interpreted
as constituent.

I.e. taking the example in Terge's original posting, #:!foo must
(following my argumentation) be read as an uninterned symbol with
symbol-name "!FOO" (modulo readtable-case.)

  -T.