[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Does *read-suppress* suppress list construction?
What, if anything, does CLtL require of the value returned from read
when *read-suppress* is true? At a glance, I might assume that read
should perform all the gross syntactic work of parsing an input, without
creating symbols or causing errors, and return no meaningful result.
Surely the result cannot be very meaningful if all tokens are
uninterpreted.
Yet on p346 it says "Note that, no matter what the value of
*read-suppress*, parentheses still continue to delimit (and construct)
lists; the #( construction continues to delimit vectors; and comments,
strings, and the quote and backquote constructions continue to be
interpreted properly." This suggests that read must still return a list
structure where appropriate, even though it is full of nil tokens. I
tried
(let ((*read-suppress* t))
(read-from-string "(a b c)"))
in 3 implementations. Vax Lisp and 3600 return (nil nil nil). Lucid
returns nil.
It's hard for me to imagine any good reason to require read to return
anything meaningful when *read-suppress* is true. If it were required
to, it would inhibit an efficient use of *read-suppress* for programs
that simply want to skip over some input, even though they know (or
expect) the input is completely legal.