NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/lisp/2906

Internet Message Format | 1992-11-18 | 3.6 KB

Path: sparky!uunet!think.com!barmar
From: [e-mail] (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: *READ-SUPPRESS* and #P syntax
Date: 18 Nov 1992 19:14:16 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 70
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: telecaster.think.com

In article <[e-mail]> [e-mail] (John P. Flanagan) writes:
>[e-mail] (Barry Margolin) writes:
>>My interpretation of *READ-SUPPRESS* is that when it doesn't say something
>>operates differently from normal, it should operate the normal way.  Thus,
>
>Maybe it's the cloudy weather affecting my judgement, but since nearly
>all sharp reader macros behave a certain way when *read-suppress* is
>non-nil, why then would you assume that a sharp reader macro that slipped
>through the specification net wouldn't behave in a similar manner?

I based my assumption on the fact that CLtL and the dpANS specifically list
only a small number of sharpsign macros in the the description of
*READ-SUPPRESS*, and make no mention of a general default effect of setting
this variable.  When interpreting a language standard (AKA "language
lawyering"), it's generally not appropriate to extrapolate from specific
instances to general cases.

>Normally these two expressions produce a vector of two elements, the symbols
>foo and bar, but when *read-suppress* is non-nil we get this instead?
>
>    #1A(foo bar)
>    => nil
>
>    #(foo bar)
>    => #(nil nil)
>
>Isn't this a bit inconsistent (if not confusing)?

I agree that it's inconsistent and confusing, but I also believe it's
implied by CLtL.

>>#( continues to construct vectors because it doesn't say that it doesn't.
>>Notice that when it's describing (, the words "and construct" are in
>                                                ^^^^^^^^^^^^^
>                        In Draft 12.24, X3J13/92-102
>                        this is not in parentheses.

Good point.  I think that was a mistake by the draft editor, although I can
see how he might not consider the parentheses to imply a technical
distinction.  Assuming my interpretation of CLtL is correct, this would be
a technical change that was never voted on by X3J13 (except insofar as we
gave a blanket approval to submit the draft for public review).

>>parentheses.  I interpret this to mean that it's just stating the obvious;
>>it wasn't repeated in the following sentence because it's even more obvious
>>because it was stated explicitly but parenthetically in the previous
>>sentence.
>
>Evidently others (besides me) do not share this interpretation, e.g.,
>CMU returns nil instead of a vector.  If you're saying that the #(
>notation should continue to construct vectors partly because the (
>notation does, but mostly because it doesn't say not to, in spite of the
>fact that the more similar #A notation doesn't, well, I'll wait for the
>book (or the movie) to come out, maybe I'll understand it then.  ;-)

Actually, I'm considering suggesting a more general change:

    When *READ-SUPPRESS* is true, READ, READ-PRESERVING-WHITESPACE, and
    READ-DELIMITED-LIST all return NIL; however, they continue to parse the
    representation of an object in the normal way, in order to skip over
    the object.  Any standard read macro that is defined to read an object
    or token will do so, but not signal an error if the object read is not
    of an appropriate type or syntax.

Sound reasonable?
--
Barry Margolin
System Manager, Thinking Machines Corp.

[e-mail]          {uunet,harvard}!think!barmar