[Openmcl-devel] Error on macro character after sharpsign colon
gb at clozure.com
Tue Jan 26 21:13:26 UTC 2010
On Tue, 26 Jan 2010, Gary Byers wrote:
> What the hell is "CLZ" ?
And, to try to be more responsive to Terje's question:
Suppose that someone decided (for barely plausible reasons) that #\;
shouldn't be a macro character and should just be a ordinary constituent
(set-macro-character #\; nil nil)
(set-syntax-from-char #\; #\a) ; just in case.
Now, ';abc is just a symbol with a "non-standard" name.
Should '#:;abc be rejected, because the first character of its name
is a macro character in a (standard) readtable that isn't otherwise
in effect ?
Signaling an error on invalid syntax discourages the use of invalid
syntax; I don't understand how it discourages careful use of custom
reader macros (or even fairly casual use of them.)
Use of custom reader macros -does- change the syntax of the language.
In a fresh lisp:
(defun factorial (n) (if (zerop n) 1 (* n (factorial (1- n)))))
(defun ! (x) (factorial x))
(defun !bar (x) (bar (factorial x)))
#\! is a constituent character, no different from (for instance) a
standard alphabetic character.
If we decide that it'd be really neat if #\! was a macro character:
(lambda (stream subchar)
(declare (ignore subchar))
(factorial (read stream)))
then we've decided that it's better (more convenient, whatever) to
have #\! be a macro-character than to have it continue to be a
constituent; we've (slightly) changed the syntax of the language
that the reader accepts: we've added the ability to use ! at read
time to introduce "factorial constants", and we've lost the ability
to use #\! as the first character of a symbol name:
3628800 ; Neat!
? (defun !foo (x) x)
> Error: value FOO is not of the expected type NUMBER. ; Less neat!
This tradeoff is something that has to be kept in mind when defining
reader macros; it isn't some obscure thing that only affects #:.
> On Tue, 26 Jan 2010, 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
>>> 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
>>>> 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
>>>> => 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
>> -- Terje Norderhaug
>> terje at in-progress.com
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel