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

Text File | 1992-11-17 | 4.2 KB | 87 lines

Newsgroups: comp.lang.lisp
Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!agate!spool.mu.edu!mixcom.com!wstar.mixcom.com!jpf
From: [e-mail] (John P. Flanagan)
Subject: Re: *READ-SUPPRESS* and #P syntax
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1992 00:06:46 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: WaveStar Technology
Lines: 76

[e-mail] (Barry Margolin) writes:

>Those comments are just what you said they are: Steele's comments.  They
>are not part of the standard, nor are they binding on implementors.  If we
>want to require that all implementors perform similarly in this respect, we
>must make them official by changing the draft accordingly.

Of course his comments aren't binding on implementors, I didn't
reference them because I thought they were.  In the absence of a clear
specification, Steele's comments seemed (at least to me) to be a
sensible, rational interpretation.  The #P confusion will probably be
resolved by the time the standard rolls around, but it's unlikely that
*all* such unspecified gaps in the spec will be completely filled in by
then.  It's therefore the implementor's responsibility to make *the*
rational (better word?)  choices until the draft officially decrees
otherwise.  Signaling an error when reading an expression like #+EXCL
#P(:type ".lsp") is not what I'd call a reasonable implementation
choice, especially when it's the Lisp user who has to endure the
consequences.  I've probably worn this poor thread out by now, but maybe
it's time to resurrect the validation suite idea to certify conformance,
after all, everything can't be reduced to the spoken word.

>I'll submit a review comment to this effect.

Thanks (my batch went out this morning).

>>Similar reasoning should also apply to the #C, #(, and #' macros although
>>an example involving the #( reader macro on p.23-22, section 23.2 of the
>>dpANS appears to suggest otherwise, i.e., #(a b c) becomes #(nil nil nil)
>>rather than nil.  The last paragraph before the examples says, "#( notation
>>continues to delimit vectors"; it doesn't say, "#( notation continues to
>>delimit [and construct] vectors" as is true with parentheses.

>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?

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)?

>#( 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.

>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.  ;-)

-jpf.
--
   __________________________________________________________________________
   WaveStar Technology           WaveStar Common Lisp        John P. Flanagan
   W344 N6855 Bayberry Court     ANSI-12.24, X3J13/92          [phone]
   Oconomowoc, WI  53066         HPUX-800/700/400/300    [e-mail]