unreading a different character than the last?
Raymond Toy
According to the CLHS, the character given to unread-char must be the
last character read from the stream. However, there are no
exceptional situations.
By this, I take it to mean the you should use the last character but
an implementation must not signal an error if you don't.
Is that right?
Ray
Barry Margolin
No, it means the consequences are undefined if you don't use the last
character. An implementation can do anything in this case. Some might
allow you to push a different character, another might signal an error
(perhaps only in safe mode), and others could just ignore the character you
supply. It would also be possible for it to corrupt the implementation's
data structures, causing the rest of your program to behave totally
unpredictably.
Basically, if the standard says an argument "must be" something, doesn't
say what happens when it isn't, all bets are off in those cases.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kaz Kylheku
Surely, ``is not required to''.
Kent M Pitman
> In article <4nvg7ni...@rtp.ericsson.se>, Raymond Toy wrote:
> >
> > According to the CLHS, the character given to unread-char must be the
> > last character read from the stream. However, there are no
> > exceptional situations.
The absence of exceptional situations does not mean "this function has no
exceptional situations". It means "no text was put here".
The exceptional situations field is not a complete enumeration of
exceptional situations. Exceptional situations may go here or in the
body description. However, there is no guarantee made that any
function will not signal exceptional situations beyond those
identified.
Unlike Java, Common Lisp does not intend the "exceptional situations"
to be an issue of program semantics. Handling of signaled errors when
the underlying exceptional situation is correctly detected and
formally signaled IS a matter of semantics, but there is a "blank
space" in there that is intentional.
An example I often use to help people see why is that of a "black box"
implementation. Suppose you had a Common Lisp that was implemented by
just showing the program text to someone elsewhere on the internet and
asking them what to type out and/or return. Then even things like (+
3 4) might get I/O errors or network errors or other things because
the process of asking the remote oracle might be slow and error-prone.
Of course, such an implementation might not be very marketworthy but
it is permitted as conforming. In practice we don't see deviations
from the norm quite this extreme exactly because market forces protect
us from them as was predicted would happen, but there could be
situations where analogous situations do occur, involving "creative
solutions" that are not the ones you'd expect... so never assume that a
set of exceptional situations for a function is exhaustive unless you are
talking "with respect to a particular vendor" and unless you've verified
it with the vendor, not with the standard.
> > By this, I take it to mean the you should use the last character but
> > an implementation must not signal an error if you don't.
> ^^^^^^^^
>
> Surely, ``is not required to''.
Right.
Raymond Toy
Kent> Kaz Kylheku <k...@ashi.footprints.net> writes:
>> In article <4nvg7ni...@rtp.ericsson.se>, Raymond Toy wrote:
>> >
>> > According to the CLHS, the character given to unread-char must be the
>> > last character read from the stream. However, there are no
>> > exceptional situations.
Kent> The absence of exceptional situations does not mean "this function has no
Kent> exceptional situations". It means "no text was put here".
Well, it does say "None", but I guess I read too much into that. I do
undertand what you are saying and Barry did say about this.
Ray
Kent M Pitman
> >>>>> "Kent" == Kent M Pitman <pit...@world.std.com> writes:
>
> Kent> Kaz Kylheku <k...@ashi.footprints.net> writes:
> >> In article <4nvg7ni...@rtp.ericsson.se>, Raymond Toy wrote:
> >> >
> >> > According to the CLHS, the character given to unread-char must be the
> >> > last character read from the stream. However, there are no
> >> > exceptional situations.
>
> Kent> The absence of exceptional situations does not mean "this function has no
> Kent> exceptional situations". It means "no text was put here".
>
> Well, it does say "None", but I guess I read too much into that.
You not only "overinterpreted" but "misinterpreted". That is, you are not
merely inferring information where none is offered but you are misjudging
the meanings of words that do have meaning.
What is an exceptional situation is a SUBJECTIVE/DEFINITIONAL judgment.
Exceptional situation does NOT have anything to do with signaling.
This is the reason that section is not called "signals" or "conditions"
or something.
Exceptional situations exist whether or not detected. Moreover,
signaling does not imply an exceptional situation.
A floating point underflow may be an untrapped exceptional situation in
some valid IEEE arithmetic situations. Therefore, the failure to signal
an error does not imply that something exceptional may have happened.
A call to ERROR may signal something but it is still "normal" not
"exceptional" for this to be so. That is, while an erring function may be
calling ERROR as part of its exceptional situations part, a call to ERROR
in and of itself may not be "exceptional". It might just be a use of the
ERROR function for the ordinary purpose of invoking the signaling and
handling mechanisms, all of which are well-defined. That is,
(defun zero ()
(handler-bind ((error #'(lambda (c)
(declare (ignore c))
(return-from zero 0))))
(error "Handle me.")))
does not contain any exceptional situations. It is simply a function that
constantly returns 0.
So since you can neither conclude things from the presence nor the absence
of text in the Exceptional Situations section, you are indeed reading more
into it than is intended, but you are doing so in part, I'm betting, because
you misunderstand an "Exceptional Situation" to be a requirement or permission
to signal or not signal, and it isn't that at all.
> I do undertand what you are saying and Barry did say about this.
It is further true, and I didn't go look but this is probably what
Barry told you, that the division of the spec into "body definition"
and "exceptional situations" for each dictionary entry was
incompletely done. Had it been more thorough, we might have voted to
give the item more weight. But the fact is that the break is PURELY
editorial and was incompletely done (due to budget limitations--we
just didn't have time for this degree of nitpicking) and therefore it
behooves you for practical reasons as well to treat the division of
this section from the rest of the definition as "uininteresting". But
in this regard, one reason we chose the name "Exceptional Situations"
for the text-division name was that it in fact was a subjective line
that was not intended to be formally possible (for reasons I cited
above) to do "exhaustive partition analysis" about....
Raymond Toy
Kent> So since you can neither conclude things from the presence nor the absence
Kent> of text in the Exceptional Situations section, you are indeed reading more
Kent> into it than is intended, but you are doing so in part, I'm betting, because
Kent> you misunderstand an "Exceptional Situation" to be a requirement or permission
Kent> to signal or not signal, and it isn't that at all.
Yes that was part of it, but not all of it. Since the the text said
it must be the same character, I had expected the exceptional
situations part to say something about this requirement.
Like the section on the function +. The exceptional situations
mentions something about what might happen if the args aren't
numbers.
On the other hand, if it didn't mention exceptional situations, I
would have assumed something like this anyway since adding non-numbers
isn't well defined.
>> I do undertand what you are saying and Barry did say about this.
Kent> It is further true, and I didn't go look but this is probably what
Kent> Barry told you, that the division of the spec into "body definition"
Kent> and "exceptional situations" for each dictionary entry was
Kent> incompletely done. Had it been more thorough, we might have voted to
He said basically if it it doesn't say so, it's undefined, but I don't
want to put words in his mouth.
Kent> give the item more weight. But the fact is that the break is PURELY
Kent> editorial and was incompletely done (due to budget limitations--we
Kent> just didn't have time for this degree of nitpicking) and therefore it
Kent> behooves you for practical reasons as well to treat the division of
Kent> this section from the rest of the definition as "uininteresting". But
Kent> in this regard, one reason we chose the name "Exceptional Situations"
Kent> for the text-division name was that it in fact was a subjective line
Kent> that was not intended to be formally possible (for reasons I cited
Kent> above) to do "exhaustive partition analysis" about....
I didn't expect an exhaustive partition analysis. Catching all of
these isn't easy and fixing isn't easy either.
Ray
Barry Margolin
Raymond Toy <t...@rtp.ericsson.se> wrote:
>Yes that was part of it, but not all of it. Since the the text said
>it must be the same character, I had expected the exceptional
>situations part to say something about this requirement.
>
>Like the section on the function +. The exceptional situations
>mentions something about what might happen if the args aren't
>numbers.
>
>On the other hand, if it didn't mention exceptional situations, I
>would have assumed something like this anyway since adding non-numbers
>isn't well defined.
There are some general principles that apply to all function descriptions,
explained in one of the introductory sections of the standard. The
Exceptional Situations sections often don't go into detail about situations
that are covered by those rules.
In some cases details were provided, even though the might be redundant, to
aid in understanding. But the absence of those details does not mean that
the general rules stop applying.
Raymond Toy
Barry> In article <4nele88...@rtp.ericsson.se>,
Barry> Raymond Toy <t...@rtp.ericsson.se> wrote:
>> Yes that was part of it, but not all of it. Since the the text said
>> it must be the same character, I had expected the exceptional
>> situations part to say something about this requirement.
>>
>> Like the section on the function +. The exceptional situations
>> mentions something about what might happen if the args aren't
>> numbers.
>>
>> On the other hand, if it didn't mention exceptional situations, I
>> would have assumed something like this anyway since adding non-numbers
>> isn't well defined.
Barry> There are some general principles that apply to all function descriptions,
Barry> explained in one of the introductory sections of the standard. The
Barry> Exceptional Situations sections often don't go into detail about situations
Barry> that are covered by those rules.
Barry> In some cases details were provided, even though the might be redundant, to
Barry> aid in understanding. But the absence of those details does not mean that
Barry> the general rules stop applying.
I need to reread those introductory sections again. It's been a
while, and I guess I've forgotten important parts of it....
Thanks,
Ray