From: Lars Brinkhoff
Subject: *read-suppress* and undefined sharpsign reader macros
Date:
Message-ID: <851xr64ix7.fsf@junk.nocrew.org>
A question for the language lawyers:
Assuming #? is an undefined sharpsign reader macro, what should
(let ((*read-suppress* t)) (read-from-string "#? 1")) return?
The CLHS page for *read-suppress* mentions dispatching macro
characters, but doesn't say how to handle the undefined ones.
At least one popular implementation returns nil and 4.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
From: james anderson
Subject: Re: *read-suppress* and undefined sharpsign reader macros
Date:
Message-ID: <3FDD8A38.E8AF662D@setf.de>
Lars Brinkhoff wrote:
>
> A question for the language lawyers:
>
> Assuming #? is an undefined sharpsign reader macro, what should
> (let ((*read-suppress* t)) (read-from-string "#? 1")) return?
>
> The CLHS page for *read-suppress* mentions dispatching macro
> characters, but doesn't say how to handle the undefined ones.
it does say that "Dispatching macro characters continue to parse an infix
numerical argument, and invoke the dispatch function". while it is not clear
to this reader, whether "the dispatch function" necessarily means the function
which implements the syntax for the sub-char, as opposed to the #\#, the last
sentence in the note does imply that it is the sub-char-specific function
which will be called.
>
> At least one popular implementation returns nil and 4.
>
another popular implementation does not return. it attempts to locate a
function to call and signals an error when it observes the #? is not defined.
? what is an implementation supposed to do with syntax which it cannot scan as
extended tokens or lists of same?
...
From: Lars Brinkhoff
Subject: Re: *read-suppress* and undefined sharpsign reader macros
Date:
Message-ID: <85wu8y1ex8.fsf@junk.nocrew.org>
james anderson <··············@setf.de> writes:
> Lars Brinkhoff wrote:
> > Assuming #? is an undefined sharpsign reader macro, what should
> > (let ((*read-suppress* t)) (read-from-string "#? 1")) return?
> >
> > The CLHS page for *read-suppress* mentions dispatching macro
> > characters, but doesn't say how to handle the undefined ones.
>
> it does say that "Dispatching macro characters continue to parse an
> infix numerical argument, and invoke the dispatch function". while
> it is not clear to this reader, whether "the dispatch function"
> necessarily means the function which implements the syntax for the
> sub-char, as opposed to the #\#, the last sentence in the note does
> imply that it is the sub-char-specific function which will be
> called.
Agreed, but I wonder what should happen when there is no such
function?
> > At least one popular implementation returns nil and 4.
> another popular implementation does not return. it attempts to
> locate a function to call and signals an error when it observes the
> #? is not defined.
But shouldn't binding *read-suppress* to t make the reader not signal
any errors?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff <·········@nocrew.org> writes:
> But shouldn't binding *read-suppress* to t make the reader not signal
> any errors?
The "spirit" of *read-suppress* being T is to say "I am inside a
failing #+ or #-." Nearly always, this means, "I am parsing a definition
not intended for my own implementation. I had better tread very lightly."
My feeling has generally been that (a) implementations should try to be
tolerant and (b) users should not expect tolerance.
A user can always create dummy definitions for readmacros used only in
certain implementations that just reads and discards characters.
Remember that in some cases with failing conditionals, it can be due to file
being trasmitted in the wrong file transfer mode or incompletely transferred,
so suppressing all errors is probably wrong.
From: james anderson
Subject: Re: *read-suppress* and undefined sharpsign reader macros
Date:
Message-ID: <3FDDAC7F.B9AB5ABE@setf.de>
Lars Brinkhoff wrote:
>
> ...
>
> But shouldn't binding *read-suppress* to t make the reader not signal
> any errors?
>
1. i did not find that prescription anywhere.
2. i did find text which implies that the function is to be called. to wit,
that it must be prepared to accept a nil value for the prefix arg
3. i do find a passage which specifies that the reader will still signal
errors for other syntax errors, eg the default handlers for unbalanced close
parentheses, unreadable syntax, etc.
4. i cannot imagine another method which would scan and skip syntax for which
the reader is not, in specific, prepared.
> --
> Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
> Brinkhoff Consulting http://www.brinkhoff.se/
From: Lars Brinkhoff
Subject: Re: *read-suppress* and undefined sharpsign reader macros
Date:
Message-ID: <85ptepp4ej.fsf@junk.nocrew.org>
james anderson <··············@setf.de> writes:
ja> 4. i cannot imagine another method which would scan and skip syntax for which
ja> the reader is not, in specific, prepared.
Kent M Pitman <······@nhplace.com> writes:
KMP> The "spirit" of *read-suppress* being T is to say "I am inside a
KMP> failing #+ or #-."
Indeed the question came up in the implementation of #+ and #-.
KMP> A user can always create dummy definitions for readmacros used only in
KMP> certain implementations that just reads and discards characters.
Tim Bradshaw <···@cley.com> writes:
TFB> I think it's clear that in general the answer has to be `give up and
TFB> signal an error'
Thank you all for your guidance. It would seem like it's quite
reasonable to signal an error.
SBCL doesn't do that, however. Any SBCL developer want to chime in?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
* Lars Brinkhoff wrote:
> Agreed, but I wonder what should happen when there is no such
> function?
I think it's clear that in general the answer has to be `give up and
signal an error', since the implementation has no idea at all what to
expect in the stream at this point, even to the extent that it cannot
know when the next legal thing to look at starts. I mean, there's
nothing to stop someone coming along and defining a readmacro which,
say, reads an exactly 80 column punched card image, then returns it as
a string.
--tim