The dictionary entry for READ-DELIMITED-LIST doesn't say whether it
must read a proper list or not. What is the correct behavior when a
dot character is encountered on the input stream? Corman Lisp 1.5
will read an improper list:
> Corman Lisp 1.5 Copyright (c) 2001 Roger Corman. All rights reserved.
> Type :quit to exit.
> ? (read-delimited-list #\))
> 1 2 3 4 . 5)
> (1 2 3 4 . 5)
> ?
CMU CL 18c will signal an error:
> CMU Common Lisp 18c, running on eco-fs1.irtnog.org
> Send questions and bug reports to your local CMU CL maintainer,
> or to ··········@cons.org. and ·········@cons.org. respectively.
> Loaded subsystems:
> Python 1.0, target Intel x86
> CLOS based on PCL version: September 16 92 PCL (f)
> * (read-delimited-list #\))
> 1 2 3 4 . 5)
>
> Reader error on #<Two-Way Stream, Input = #<Synonym Stream to
> SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>>:
> Dot context error.
>
> Restarts:
> 0: [ABORT] Return to Top-Level.
>
> Debug (type H for help)
>
> (COMMON-LISP::%READER-ERROR
> #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output
> #= #<Synonym Stream to SYSTEM:*STDOUT*>>
> "Dot context error.")
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no
> longer exists:
> target:code/reader.lisp.
> 0] 0
>
> *
> 5
> * Warning: Ignoring unmatched close parenthesis.
--
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
I'm proud of my Northern Tibetian heritage! (http://www.subgenius.com)
The spec doesn't say that READ-DELIMITED-LIST *must* read
dotted tails, but since it says that READ-DELIMITED-LIST
is intended for use in writing read macros, it seems to me
that it *ought* to read an improper list even if this is not explicitly
stated.
If you are using READ-DELIMITED-LIST in a situation where you
don't want a dotted tail, but it returns one, it is easy enough to
detect the case and throw an error. But if you *want* a dotted
tail and READ-DELIMITED-LIST *doesn't* let you, then you are
forced to write a lot more code.
Apparently, though, no one consulted *me* on this point.
Here are a couple more data points for you:
--------------------------------------
clisp-2.28
[1]> (read-delimited-list #\))
1 2 3 4 . 5)
*** - READ from #<IO SYNONYM-STREAM *TERMINAL-IO*>: token "." not allowed here
1. Break [2]> 5
1. Break [2]>
-------------------------------------
Lispworks 4.2
CL-USER 1 > (read-delimited-list #\))
1 2 3 4 . 5)
(1 2 3 4 (#\. . #\.) 5)
This last one is baffling.
On Mon, 17 Jun 2002 11:14:15 GMT, Joe Marshall wrote:
> The spec doesn't say that READ-DELIMITED-LIST *must* read
> dotted tails, but since it says that READ-DELIMITED-LIST
> is intended for use in writing read macros, it seems to me
> that it *ought* to read an improper list even if this is not explicitly
> stated.
Actually, the spec says that it /doesn't/ read dotted lists:
"If [the next non-whitespace character in the input stream] is a
constituent or escape character, then READ is used to read an
object, which is added to the end of the list."
When the next character is a lone dot, the call to READ will signal
an error.
--
I'm sure the above forms some sort of argument in this debate, but I'm not
sure whether it's for or against.
-- Boris Schaefer
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
"Paul Foley" <·······@actrix.gen.nz> wrote in message ···················@mycroft.actrix.gen.nz...
> On Mon, 17 Jun 2002 11:14:15 GMT, Joe Marshall wrote:
>
> > The spec doesn't say that READ-DELIMITED-LIST *must* read
> > dotted tails, but since it says that READ-DELIMITED-LIST
> > is intended for use in writing read macros, it seems to me
> > that it *ought* to read an improper list even if this is not explicitly
> > stated.
>
> Actually, the spec says that it /doesn't/ read dotted lists:
>
> "If [the next non-whitespace character in the input stream] is a
> constituent or escape character, then READ is used to read an
> object, which is added to the end of the list."
>
> When the next character is a lone dot, the call to READ will signal
> an error.
But consider section 2.3.3
``If a token consists solely of dots (with no escape characters),
then an error of type reader-error is signaled, except in one
circumstance: if the token is a single dot and appears in a
situation where dotted pair notation permits a dot, then it is
accepted as part of such syntax and no error is signaled.''
I think this could be considered a circumstance where the dotted
pair notation permits a dot.
Joe, Paul, thanks for your responses. I'll test for a proper list
explicitly and act accordingly in my reader macros.
--
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
I'm proud of my Northern Tibetian heritage! (http://www.subgenius.com)