Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
#P?
Siutation: My code was trying to read in some files which contain
references to pathnames using the #P syntax. Lucid and Franz have
different syntaxes for the object following the #P. Lucid allows only
a string, whereas Franz supports both strings and lists in this
position. Lucid signals an error when given an expression of the form
#P followed by a list, since that violates its #P reader.
So far, so good. However, in (lucid) lcl4.1b, you can't avoid
signaling this error when reading a Franz-derived #P pathname.
Putting a #-LUCID or #+EXCL qualifier in front of the form doesn't
seem to work; it reads enough to signal the error anyway.
One would imagine that the intent of using READ-SUPPRESS to implement
the *FEATURES* idea was to avoid signaling errors associated with just
this kind of implementation-specific extension.
However, strictly speaking, this behavior is allowed by pp. 522 ff. of
CLtL2. It appears that the appropriate section of the new dpAns spec
agrees with CLtl2 in this matter. I couldn't swear I got to the right
section, but there was one in dict-reader.tex that mirrored 22.1.2
pretty well, and I didn't find any reference to #P there.
Is it the intent of dpAns that
(defvar my-path
#+EXCL #P(:type "lisp")
#+LUCID #P".lisp"
)
can cause an error?
--
---------------------------------------------------------------
·······@ptolemy.arc.nasa.gov
In article <·····················@kronos.arc.nasa.gov> ·······@kepler.arc.nasa.gov (Andrew Philpot) writes:
>Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
>#P?
I think it's a reasonable suggestion. Please submit it as a public review
comment.
>One would imagine that the intent of using READ-SUPPRESS to implement
>the *FEATURES* idea was to avoid signaling errors associated with just
>this kind of implementation-specific extension.
Note that *READ-SUPPRESS* can't possibly satisfy all syntax portability
problems. As you've discovered, it can only help when the
implementation-specific syntax satisfies the expectations of those of us
specifying *READ-SUPPRESS*. When *READ-SUPPRESS* is true, the reader still
has to be able to parse expressions sufficiently to skip over them.
>However, strictly speaking, this behavior is allowed by pp. 522 ff. of
>CLtL2. It appears that the appropriate section of the new dpAns spec
>agrees with CLtl2 in this matter. I couldn't swear I got to the right
>section, but there was one in dict-reader.tex that mirrored 22.1.2
>pretty well, and I didn't find any reference to #P there.
Basically, the problem is that when we added #P syntax we never updated
*READ-SUPPRESS*. The definition of #P is that it's followed by a string,
not an expression.
>Is it the intent of dpAns that
>
> (defvar my-path
> #+EXCL #P(:type "lisp")
> #+LUCID #P".lisp"
> )
>
>can cause an error?
As currently written, yes. I think it was the original intent of #+ to
allow this kind of code, though.
Of course, you can always work around this by calling MAKE-PATHNAME rather
than using a pathname literal:
(defvar my-path
#+EXCL (make-pathname :type "lisp")
#+lucid #p".lisp")
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
·······@kepler.arc.nasa.gov (Andrew Philpot) writes:
>Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
>#P?
Yes!
[... stuff deleted ...]
>However, strictly speaking, this behavior is allowed by pp. 522 ff. of
>CLtL2. It appears that the appropriate section of the new dpAns spec
>agrees with CLtl2 in this matter. I couldn't swear I got to the right
>section, but there was one in dict-reader.tex that mirrored 22.1.2
>pretty well, and I didn't find any reference to #P there.
Strictly speaking, I don't think this behavior is allowed. Section
2.4.8.14, p.2-33 in the dpANS makes the following statement:
"#P"..." is equivalent to #.(parse-namestring "...")."
Now, from the description for *read-suppress* on p.23-22, section 23.2:
"The #. notation reads the following object in suppressed mode but
does not evaluate it. The object is discarded and nil is produced."
note: IMHO, the dpANS should explicitly mention #P in this section as well.
Unless I've missed something here, I'll add this suggestion to my
list of public review comments to be mailed next week.
>Is it the intent of dpAns that
> (defvar my-path
> #+EXCL #P(:type "lisp")
> #+LUCID #P".lisp"
> )
>can cause an error?
No. I don't think Lucid should be signaling an error in this case.
-jpf.
--
__________________________________________________________________________
WaveStar Technology WaveStar Common Lisp John P. Flanagan
W344 N6855 Bayberry Court ANSI-12.24, X3J13/92 (414) 367-5014
Oconomowoc, WI 53066 HPUX-800/700/400/300 ···@wstar.mixcom.com
In article <····················@wstar.mixcom.com> ···@wstar.mixcom.com (John P. Flanagan) writes:
>Strictly speaking, I don't think this behavior is allowed. Section
>2.4.8.14, p.2-33 in the dpANS makes the following statement:
>
> "#P"..." is equivalent to #.(parse-namestring "...")."
However, that doesn't say what "#P(...)" is equivalent to.
Had it said
#P<expression> is equivalent to #.(parse-namestring '<expression>)
then your reasoning would be correct. Perhaps this would be a better
definition of #P; please suggest it in your review comments.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
······@think.com (Barry Margolin) writes:
>In article <····················@wstar.mixcom.com> ···@wstar.mixcom.com (John P. Flanagan) writes:
>>Strictly speaking, I don't think this behavior is allowed. Section
>>2.4.8.14, p.2-33 in the dpANS makes the following statement:
>>
>> "#P"..." is equivalent to #.(parse-namestring "...")."
>However, that doesn't say what "#P(...)" is equivalent to.
Yes, but why does this matter when *read-suppress* is non-nil?
Consider Steele's comments from section 22.1.4, p.537 in CLtL2 with
regard to `#P"..." is equivalent to #.(parse-namestring "...")':
["Presumably this was meant to be taken descriptively and not literally."]
...
["I interpret the intent of the vote to be that #p reads a following form,
which should be a string, that is then converted to a pathname as if by
application of the standard function parse-namestring."]
When the value of *read-suppress* is non-nil, it shouldn't matter what the
following form is unless the Sharpsign-P reader evaluates that form; as with
other standard # dispatching macro readers such as #\, #B, #O, #X, #R, #*,
#A, #S, #:, ##, and #., the Sharpsign-P reader returns nil instead.
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.
-jpf
--
__________________________________________________________________________
WaveStar Technology WaveStar Common Lisp John P. Flanagan
W344 N6855 Bayberry Court ANSI-12.24, X3J13/92 (414) 367-5014
Oconomowoc, WI 53066 HPUX-800/700/400/300 ···@wstar.mixcom.com
In article <·····················@wstar.mixcom.com> ···@wstar.mixcom.com (John P. Flanagan) writes:
>Consider Steele's comments from section 22.1.4, p.537 in CLtL2 with
>regard to `#P"..." is equivalent to #.(parse-namestring "...")':
>["I interpret the intent of the vote to be that #p reads a following form,
> which should be a string, that is then converted to a pathname as if by
> application of the standard function parse-namestring."]
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.
I'll submit a review comment to this effect.
>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,
#( 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
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.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
······@think.com (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 (414) 367-5014
Oconomowoc, WI 53066 HPUX-800/700/400/300 ···@wstar.mixcom.com
In article <·····················@wstar.mixcom.com> ···@wstar.mixcom.com (John P. Flanagan) writes:
>······@think.com (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.
······@think.com {uunet,harvard}!think!barmar
······@think.com (Barry Margolin) writes:
>In article <·····················@wstar.mixcom.com> ···@wstar.mixcom.com (John P. Flanagan) writes:
>>······@think.com (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.
According to my copy only three sharp reader macros, #C, #(, and #',
were left out of the description for *READ-SUPPRESS*, that's hardly a
small number! We have twelve *specific* reader macro examples to ponder
in that description of *READ-SUPPRESS*; excluding #=, all produce nil when
*READ-SUPPRESS* is non-nil. How much extrapolation is required to properly
reconcile the behavior of #C, #(, or #' given this kind of evidence?
>>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.
One man's implication is another man's extrapolation? ;-)
>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?
Yes, very much so, but you're already tempting fate (**EXTRAPOLATION**)
by not mentioning READ-FROM-STRING!
-jpf.
--
__________________________________________________________________________
WaveStar Technology WaveStar Common Lisp John P. Flanagan
W344 N6855 Bayberry Court ANSI-12.24, X3J13/92 (414) 367-5014
Oconomowoc, WI 53066 HPUX-800/700/400/300 ···@wstar.mixcom.com
Date: Tue, 10 Nov 1992 20:49 EST
From: Andrew Philpot <·······@kepler.arc.nasa.gov>
Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
#P?
I am no dpANS language lawyer, but it certainly seems "right" that
*READ-SUPPRESS* should prevent #P from doing syntax-checking on the
literal pathname.
Siutation: My code was trying to read in some files which contain
references to pathnames using the #P syntax. Lucid and Franz have
different syntaxes for the object following the #P. Lucid allows only
a string, whereas Franz supports both strings and lists in this
position. Lucid signals an error when given an expression of the form
#P followed by a list, since that violates its #P reader.
So far, so good. However, in (lucid) lcl4.1b, you can't avoid
signaling this error when reading a Franz-derived #P pathname.
Putting a #-LUCID or #+EXCL qualifier in front of the form doesn't
seem to work; it reads enough to signal the error anyway.
One would imagine that the intent of using READ-SUPPRESS to implement
the *FEATURES* idea was to avoid signaling errors associated with just
this kind of implementation-specific extension.
However, strictly speaking, this behavior is allowed by pp. 522 ff. of
CLtL2. It appears that the appropriate section of the new dpAns spec
agrees with CLtl2 in this matter. I couldn't swear I got to the right
section, but there was one in dict-reader.tex that mirrored 22.1.2
pretty well, and I didn't find any reference to #P there.
Is it the intent of dpAns that
(defvar my-path
#+EXCL #P(:type "lisp")
#+LUCID #P".lisp"
)
can cause an error?
--
---------------------------------------------------------------
·······@ptolemy.arc.nasa.gov