Consider this pair of definitions:
(defun foo ()
(format t "The Deed is Done!")
(finish-output)
(bar))
(defun bar ()
"unspecified"
"consequences ahead"
"...and behind?")
When FOO is called, may a conforming implementation raise an error
(say) before performing and finishing the output?
Does your answer depend on whether we invoke "unspecified
consequences" (as in this case) or "undefined consequences"?
--
Marcus Breiing
In article <············@chessie.cirr.com>,
Marcus Breiing <······@2006w24.mail.breiing.com> wrote:
> Consider this pair of definitions:
>
>
> (defun foo ()
> (format t "The Deed is Done!")
> (finish-output)
> (bar))
>
> (defun bar ()
> "unspecified"
> "consequences ahead"
> "...and behind?")
>
>
> When FOO is called, may a conforming implementation raise an error
> (say) before performing and finishing the output?
>
> Does your answer depend on whether we invoke "unspecified
> consequences" (as in this case) or "undefined consequences"?
No, and no. Why would you imagine the answers could be otherwise? (And
what the fleep is a nose dragon?)
rg
From: Geoffrey Summerhayes
Subject: Re: Do Nose Dragons Travel Back in Time?
Date:
Message-ID: <e6uqs2$v82$1@nntp.aioe.org>
"Ron Garret" <·········@flownet.com> wrote in message
····································@news.gha.chartermi.net...
> In article <············@chessie.cirr.com>,
> Marcus Breiing <······@2006w24.mail.breiing.com> wrote:
>
>> Consider this pair of definitions:
>>
>>
>> (defun foo ()
>> (format t "The Deed is Done!")
>> (finish-output)
>> (bar))
>>
>> (defun bar ()
>> "unspecified"
>> "consequences ahead"
>> "...and behind?")
>>
>>
>> When FOO is called, may a conforming implementation raise an error
>> (say) before performing and finishing the output?
>>
>> Does your answer depend on whether we invoke "unspecified
>> consequences" (as in this case) or "undefined consequences"?
I'd say yes and no. FINISH-OUTPUT is implementation dependant, the
CLHS says it 'attempts' to do its work and is allowed to do nothing
if the stream is, um, uncooperative.
> No, and no. Why would you imagine the answers could be otherwise? (And
> what the fleep is a nose dragon?)
Great gobs of steaming gravy, do you really want to know?
----
Geoff
In article <············@nntp.aioe.org>,
"Geoffrey Summerhayes" <·············@hotmail.com> wrote:
> "Ron Garret" <·········@flownet.com> wrote in message
> ····································@news.gha.chartermi.net...
> > In article <············@chessie.cirr.com>,
> > Marcus Breiing <······@2006w24.mail.breiing.com> wrote:
> >
> >> Consider this pair of definitions:
> >>
> >>
> >> (defun foo ()
> >> (format t "The Deed is Done!")
> >> (finish-output)
> >> (bar))
> >>
> >> (defun bar ()
> >> "unspecified"
> >> "consequences ahead"
> >> "...and behind?")
> >>
> >>
> >> When FOO is called, may a conforming implementation raise an error
> >> (say) before performing and finishing the output?
> >>
> >> Does your answer depend on whether we invoke "unspecified
> >> consequences" (as in this case) or "undefined consequences"?
>
> I'd say yes and no. FINISH-OUTPUT is implementation dependant, the
> CLHS says it 'attempts' to do its work and is allowed to do nothing
> if the stream is, um, uncooperative.
I stand correct. I had neglected to consider the possibility that
*standard-output* could be rebound.
> > No, and no. Why would you imagine the answers could be otherwise? (And
> > what the fleep is a nose dragon?)
>
> Great gobs of steaming gravy, do you really want to know?
Since you put it that way, I guess not.
rg
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> > Marcus Breiing <······@2006w24.mail.breiing.com> wrote:
> >>
> >> When FOO is called, may a conforming implementation raise an error
> >> (say) before performing and finishing the output?
> >>
> >> Does your answer depend on whether we invoke "unspecified
> >> consequences" (as in this case) or "undefined consequences"?
>
> I'd say yes and no. FINISH-OUTPUT is implementation dependant, the
> CLHS says it 'attempts' to do its work and is allowed to do nothing
> if the stream is, um, uncooperative.
I'd agree, but that wasn't what I was after:-) Should have been more
precise.
Let's assume that this stream is cooperative. The point was that
*later*, in BAR, we see "unspecified consequences" (from two
docstings).
I was wondering if "undefined" or "unspecified" consequences can
"reach backwards", so to say.
After all, at least the "undefined" variety is said to be able to
format your harddrive and make dragons fly out of your nose:-)
--
Marcus Breiing
Marcus Breiing wrote:
> I was wondering if "undefined" or "unspecified" consequences can
> "reach backwards", so to say.
>
> After all, at least the "undefined" variety is said to be able to
> format your harddrive and make dragons fly out of your nose:-)
You know, I thought about this a little bit more and basically, the
answer is yes, in the following way. Although consequences cannot turn
into antecedences in the temporal sense, that doesn't necessarily
matter if you regard time to be an irrelevant abstraction. What I mean
is that if you change the state of a system to a state that it had
previously, it's effectively as if time had gone backwards. The only
reason you know that time hadn't in fact gone backwards is that there
is additional state outside of that system which tells you so (clock on
the wall, etc). But that might not actually matter.
For instance, if the hard drive is reformatted and the computer is
restored to factory defaults, and then rebooted, then effectively, the
undefined consquences reached all the way back to that time.
Or suppose that the code is running on some checkpointed system
(perhaps an emulator which can save its state). The undefined behavior
has the effect of restoring the system to an earlier snapshot, plus
injecting some modification which will cause a subsequent execution to
blow up. It's as if time had gone backwards and then the evolution of
state resumed along a different path. The resumed system will simply
not know what hit it!!! Someone with no information outside of that
system will have to deduce that the cause of the mysterious crash is in
the computational future. But what information would tell them that?
They will have to know about that mysterious, injected change, that
little bad input or whatever, and realize that it came from an external
manipulation; that if that little change hadn't happened, then
execution would have followed a different path, which led to a
restoring of state with that little change ...
Marcus Breiing <······@2006w24.mail.breiing.com> writes:
> Let's assume that this stream is cooperative. The point was that
> *later*, in BAR, we see "unspecified consequences" (from two
> docstings).
In your original function,
(defun bar ()
"unspecified"
"consequences ahead"
"...and behind?")
I don't see two docstrings; I see a docstring followed by two forms
(one of which has no effect).
Zach
Ron Garret wrote:
> In article <············@chessie.cirr.com>,
> Marcus Breiing <······@2006w24.mail.breiing.com> wrote:
[snip question about undefined/unspecified behaviour]
>
> No, and no. Why would you imagine the answers could be otherwise? (And
> what the fleep is a nose dragon?)
AFAICT it seems to be a corruption of "nasal demon", which is an allowed
consequence of invoking undefined behaviour in C:
http://www.catb.org/~esr/jargon/html/N/nasal-demons.html
which in turn references:
http://groups.google.com/group/comp.std.c/msg/dfe1ef367547684b?hl=en
... " Permissible undefined behaviour ranges from ignoring the situation
completely with unpredictable results, to having demons fly out of your
nose." ...
Whimsical note:
A "nasal dragon" could be like a "nasal demon", but running on ITS:
http://www.catb.org/~esr/jargon/html/D/dragon.html
;-)
--
Simon Richard Clarkstone: ··············@·····························@
hotmail.com ### "I have a spelling chequer / it came with my PC /
it plainly marks for my revue / Mistake's I cannot sea" ...
by: John Brophy (at: http://www.cfwf.ca/farmj/fjjun96/)
Marcus Breiing wrote:
> Consider this pair of definitions:
>
>
> (defun foo ()
> (format t "The Deed is Done!")
> (finish-output)
> (bar))
>
> (defun bar ()
> "unspecified"
> "consequences ahead"
> "...and behind?")
>
>
> When FOO is called, may a conforming implementation raise an error
> (say) before performing and finishing the output?
No. In Lisp, evaluation is nicely left to right. The full evaluation of
(finish-output) takes place before (bar). There is no way that any
run-time errors that occur in (bar) could take place before
(finish-output) is done, because that would imply that evaluation of
(bar) has commenced before that of (finish-output) has completed.
An expression could have an error that qualifies as compile time. For
instance, a constant with an undefined value:
(defun foo ()
...
(finish-output)
(/ 1 0))
This function returns a constant expression whose value is a division
by zero. So this could be flagged as an error even before FOO is
called, like say when FOO is being compiled. And of course it could
blow up when (/ 1 0) is being evaluated. It therefore follows that it
could blow up at any time in between also. For instance, the file
containing that function could compile cleanly, but not load. Or maybe
the call to (foo) might fail:
Error in (FOO):
You're calling a bogus function. I had meant to tell you
about that when I was compiling it, but forgot! Sorry!
debugger > _
> Does your answer depend on whether we invoke "unspecified
> consequences" (as in this case) or "undefined consequences"?
What does the word "consequence" mean? How is it related to "sequence"
and "sequential"?
:)
What you are describing would be "unspecified antecedents" rather than
consequences, right?
Marcus Breiing wrote:
> Consider this pair of definitions:
>
>
> (defun foo ()
> (format t "The Deed is Done!")
> (finish-output)
> (bar))
>
> (defun bar ()
> "unspecified"
> "consequences ahead"
> "...and behind?")
>
>
> When FOO is called, may a conforming implementation raise an error
> (say) before performing and finishing the output?
>
#'finish-output should complete executing, but who knows if the
unspecified consequences will allow the operating system to complete
its part of the task. Perhaps the Lisp process will trample on the
buffer the system call is working with. Perhaps the processor will lock
up before the kernel thread responsible for flushing output gets a
chance to execute.
Presumably, you are counting on some effect in the real world, not just
in the Lisp world. For that, you have to go outside the language, and
know how badly your Lisp implementation can blow up the rest of the
world in cases that are unspecified by the standard, and just how bad
your particular case is.