Additionally, sbcl ignores #\. macro character when inside a list:
CL-USER> (set-macro-character #\. (lambda (&rest ignore) (declare
(ignore ignore)) (print "ouch")))
T
CL-USER> .
"ouch"
"ouch"
CL-USER> '(a . b)
(A . B)
CL-USER> `(a . ,'b)
(A . B)
Likely this does not matter at all, but indeed it looks like it fails
to conform.
In article
<····································@w24g2000prd.googlegroups.com>,
budden <········@gmail.com> wrote:
> Additionally, sbcl ignores #\. macro character when inside a list:
>
> CL-USER> (set-macro-character #\. (lambda (&rest ignore) (declare
> (ignore ignore)) (print "ouch")))
> T
> CL-USER> .
>
> "ouch"
> "ouch"
> CL-USER> '(a . b)
> (A . B)
> CL-USER> `(a . ,'b)
> (A . B)
>
> Likely this does not matter at all, but indeed it looks like it fails
> to conform.
I don't know if that is an error, but implementations
have different behavior:
Camp "ouch"
Clozure CL
ECL
CLISP
MCL
Genera
Camp "non ouch"
CMUCL
LispWorks
SBCL
SCL
--
http://lispm.dyndns.org/
According to 2.2 Reader Algorithm, http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm,
> 4. If x is a terminating or non-terminating macro character then its associated reader macro function is called with two arguments, the input stream and x.
...
> 7. If x is a constituent character, then it begins a token.
So, we see macro characters have a priority.
Next, 2.1.4 Character Syntax Types http://www.lispworks.com/documentation/HyperSpec/Body/02_ad.htm
says that #\. is constituent.
That is, in (a . b) #\. character would give a token. So, if there is
a macro-character on #\. , it need to be processed.
But it is not.
Accordingly, section 2.4.1 Left-Parenthesis
http://www.lispworks.com/documentation/HyperSpec/Body/02_da.htm
says,
> If a token that is just a dot not immediately preceded by an escape character is read after some object then exactly one more object must follow the dot, possibly preceded or followed by whitespace[2] or a comment...
So, this strengthens the idea that "." should be treated as a token.
From: Tobias C. Rittweiler
Subject: Re: Sbcl 1.0.22 - one bug, one non-conformance
Date:
Message-ID: <873ahuim9j.fsf@freebits.de>
budden <········@gmail.com> writes:
> Accordingly, section 2.4.1 Left-Parenthesis [...]
> > If a token that is just a dot not immediately preceded by an escape
> > character is read after some object then exactly one more object must
> > follow the dot, possibly preceded or followed by whitespace[2] or a
> > comment...
>
> So, this strengthens the idea that "." should be treated as a token.
"a token ... is read" does not necessarily mean that the full Reader
Algorithm (section 2.2) is employed. In this case it could be
interpreted to mean an invocation of an implementation-internal
READ-TOKEN, or some tantamount function specific for this case.
-T.
> "a token ... is read" does not necessarily mean that the full Reader
> Algorithm (section 2.2) is employed. In this case it could be
> interpreted to mean an invocation of an implementation-internal
> READ-TOKEN, or some tantamount function specific for this case.
Maybe, again, I don't insist. Though there the following hints:
i) token from 2.2 and from 2.4.5 are hyperlinked to one glossary
entry.
Only one way to read a token is defined in an implementation. Am I
wrong?
If so, all tokens may be readed only with the algorithm from section
2.2.
ii) There seem to be no way to completely redefine action of #\.
without
redefining both #\` and #\( in "non ouch" implementations. So, in
fact, a large
portion of lisp reader needs to be rewritten to do so. I bet these
implementation would not
honer set-syntax-from-char too. I don't think this was an
intention of CL standard developers.
From: Tobias C. Rittweiler
Subject: Re: Sbcl 1.0.22 - one bug, one non-conformance
Date:
Message-ID: <87myg2h02h.fsf@freebits.de>
budden <········@gmail.com> writes:
> If so, all tokens may be readed only with the algorithm from section
> 2.2.
But not the full algorithm; reading of tokens is specified by items 8,
9, and 10 in section 2.2.
> ii) There seem to be no way to completely redefine action of #\.
> without redefining both #\` and #\( in "non ouch" implementations.
This is _sensible_; the Consing Dot is idiosyncratic, that is entirely
local behaviour of #\(.
-T.
> But not the full algorithm; reading of tokens is specified by items 8, 9, and 10 in section 2.2.
I disagree. Do macro characters act inside a list on a tokens other
than dot? Yes, they do. This means the entire reader algorithm is
processed. To add, it is directly stated in 2.4.1 that list reader
calls read recursively to read in a series of objects. No other
actions are suggested/allowed. So, the only way to get a token from
dot is through reader algoirthm from section 2.2
From: Tobias C. Rittweiler
Subject: Re: Sbcl 1.0.22 - one bug, one non-conformance
Date:
Message-ID: <871vx5mmim.fsf@freebits.de>
budden <········@gmail.com> writes:
> Additionally, sbcl ignores #\. macro character when inside a list:
>
> CL-USER> (set-macro-character #\. (lambda (&rest ignore) (declare
> (ignore ignore)) (print "ouch")))
> T
> CL-USER> .
>
> "ouch"
> "ouch"
> CL-USER> '(a . b)
> (A . B)
> CL-USER> `(a . ,'b)
> (A . B)
>
> Likely this does not matter at all, but indeed it looks like it fails
> to conform.
I actually came to agree that it does _not_ conform. When I initially
looked at your posting, I thought you were making #\. a non-terminating
macro-character, but you aren't. I'll see to get this fixed.
Thanks for you patience,
-T.