In section 1.4.2 of CLtS, the result of a situation where the consequences are unspecified
is said to be 'unpredictable but harmless'.
What does 'harmless' mean? Can it signal an error or other condition, or do some
other kind of nonlocal transfer of control?
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> In section 1.4.2 of CLtS, the result of a situation where the
> consequences are unspecified is said to be 'unpredictable but
> harmless'.
>
> What does 'harmless' mean? Can it signal an error or other
> condition, or do some other kind of nonlocal transfer of control?
(Disclaimer: The document means whatever it means. My remarks here are
just my opinion and should not be taken with any greater weight than
that.)
In direct answer to your question, yes, it can signal an error or do
other transfers of control within Lisp, I think. If it were only a
data issue, it would be an "implementation-dependent result". It's
the use of the generalized term "consequences" that alerts you to the
possibility of action such as transfer of control.
In prep of the standard, we had a big argument over whether this was
meaningful and/or a good idea wordingwise. I argued that if the answer
could vary, then one could still write
(if (harmlessly-different-boolean) (dangerous) (not-dangerous))
and so nothing is ever truly harmless.
I think the main champion of this term was Dick Gabriel, and as nearly
as I could tell, what he meant was "any ill consequences of this are
expected as at least a direct consequence (since indirect consequences
are hard to predict) to leave Lisp's control structures and data stores
in a conforming state." As such, it meant things like "this won't get a
segfault or try to access invalid memory". Undefined consequences is
supposedly more severe, meaning that it could cause much more severe
consequences...
But really, if I were you, I'd just not rely too heavily on the
promises of what won't happen... Those are mostly implementation
guides saying to the implementor "be gentle here if possible"; they
are hardly guarantees of "good conduct" useable in any meaningful way
by programmers.
I personally think they needlessly complicate the description of the
language and would just as soon have merged the two.
Kent M Pitman wrote:
> In direct answer to your question, yes, it can signal an error or do
> other transfers of control within Lisp, I think. If it were only a
> data issue, it would be an "implementation-dependent result". It's
> the use of the generalized term "consequences" that alerts you to the
> possibility of action such as transfer of control.
This makes it very hard to test. Ok, I'll just lump that in with
the 'undefined'. Thanks.
Pau;
Paul F. Dietz wrote:
> This makes it very hard to test. Ok, I'll just lump that in with
> the 'undefined'. Thanks.
Well, you can execute the 'unspecified' circumstance and make sure that
the test suite keeps running and that the lisp execution is not obviously
trashed. This is what distinguishes the specification from 'undefined'
which permits a conforming implementation to melt your computer into a
steaming stinking puddle of plastic, resin, and metal...
Steven M. Haflich wrote:
> Well, you can execute the 'unspecified' circumstance and make sure that
> the test suite keeps running and that the lisp execution is not obviously
> trashed.
Hmm. Maybe if I wrapped the test in an unwind-protect that jumped back
into the tests.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Kent M Pitman wrote:
>
> > In direct answer to your question, yes, it can signal an error or do
> > other transfers of control within Lisp, I think. If it were only a
> > data issue, it would be an "implementation-dependent result". It's
> > the use of the generalized term "consequences" that alerts you to the
> > possibility of action such as transfer of control.
>
> This makes it very hard to test. Ok, I'll just lump that in with
> the 'undefined'. Thanks.
Well, indeed. The entire realm of undefined effects and consequences
are exactly about being hard to test. You could keep a database of
the fact that it transfers at all, without regard as to where, and
note when some implementations do and some don't, just in case the
community wants to consider consolidating. Not that they are required
to, though. It just might turn up some cases people didn't realize we
diverged on.
Kent M Pitman <······@world.std.com> writes:
> "Paul F. Dietz" <·····@dls.net> writes:
> > In section 1.4.2 of CLtS, the result of a situation where the
> > consequences are unspecified is said to be 'unpredictable but
> > harmless'. What does 'harmless' mean? Can it signal an error or
> > other condition, or do some other kind of nonlocal transfer of
> > control?
> In direct answer to your question, yes, it can signal an error or do
> other transfers of control within Lisp, I think.
This sounds a bit like the term "boundedly undefined" used in PowerPC
documentation:
The results of executing a given instruction are said to be
boundedly undefined if they could have been achieved by executing an
arbitrary sequence of instructions, starting in the state the
machine was in before executing the given instruction.
"Lars Brinkhoff" <·········@nocrew.org> wrote in message ···················@junk.nocrew.org...
> Kent M Pitman <······@world.std.com> writes:
> > "Paul F. Dietz" <·····@dls.net> writes:
> > > In section 1.4.2 of CLtS, the result of a situation where the
> > > consequences are unspecified is said to be 'unpredictable but
> > > harmless'. What does 'harmless' mean? Can it signal an error or
> > > other condition, or do some other kind of nonlocal transfer of
> > > control?
> > In direct answer to your question, yes, it can signal an error or do
> > other transfers of control within Lisp, I think.
>
> This sounds a bit like the term "boundedly undefined" used in PowerPC
> documentation:
>
> The results of executing a given instruction are said to be
> boundedly undefined if they could have been achieved by executing an
> arbitrary sequence of instructions, starting in the state the
> machine was in before executing the given instruction.
Who taught the lawyer nerdspeak? C'mon, fess up.