From: Samir Barjoud
Subject: Interpretation of "The consequences are unspecified"
Date:
Message-ID: <wkd7qfkxyn.fsf@mindspring.com>
The Hyperspec defines "The consequences are unspecified" in section
1.4.2.
..........
<The consequences are unspecified>
This means that the consequences are unpredictable but
harmless. Implementations are permitted to specify the consequences of
this situation. No conforming code may depend on the results or
effects of this situation, and all conforming code is required to
treat the results and effects of this situation as unpredictable but
harmless. For example, ``if the second argument to shared-initialize
specifies a name that does not correspond to any slots accessible in
the object, the results are unspecified.''
..........
Is an implementation permitted to signal an error for situations in
which the consequences are unspecified?
Also, is "will not permanently damage the running LISP image, but may
signal an error" the proper interpretation of "harmless"?
--
Samir Barjoud
·····@mindspring.com
From: Andrew Cooke
Subject: Re: Interpretation of "The consequences are unspecified"
Date:
Message-ID: <87bess$ue4$1@nnrp1.deja.com>
In article <··············@mindspring.com>,
Samir Barjoud <·····@mindspring.com> wrote:
>
> The Hyperspec defines "The consequences are unspecified" in section
> 1.4.2.
> ..........
> <The consequences are unspecified>
> This means that the consequences are unpredictable but
> harmless. Implementations are permitted to specify the consequences of
> this situation. No conforming code may depend on the results or
> effects of this situation, and all conforming code is required to
> treat the results and effects of this situation as unpredictable but
> harmless. For example, ``if the second argument to shared-initialize
> specifies a name that does not correspond to any slots accessible in
> the object, the results are unspecified.''
> ..........
>
> Is an implementation permitted to signal an error for situations in
> which the consequences are unspecified?
>
> Also, is "will not permanently damage the running LISP image, but may
> signal an error" the proper interpretation of "harmless"?
Doesn't the rider about "no conforming code may depend..." mean that if
you have to ask, then your code is non-conforming? In which case, just
go with what your local Lisp does (and don't expect it to work
elsewhere).
I know this isn't much help - sorry (I'm no expert on Lisp - that's just
me take on the logic implicit in the quote).
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Kent M Pitman
Subject: Re: Interpretation of "The consequences are unspecified"
Date:
Message-ID: <sfw66w43edb.fsf@world.std.com>
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
> In article <··············@mindspring.com>,
> Samir Barjoud <·····@mindspring.com> wrote:
> >
> > The Hyperspec defines "The consequences are unspecified" in section
> > 1.4.2.
> > ..........
> > <The consequences are unspecified>
> > This means that the consequences are unpredictable but
> > harmless. Implementations are permitted to specify the consequences of
> > this situation. No conforming code may depend on the results or
> > effects of this situation, and all conforming code is required to
> > treat the results and effects of this situation as unpredictable but
> > harmless. For example, ``if the second argument to shared-initialize
> > specifies a name that does not correspond to any slots accessible in
> > the object, the results are unspecified.''
> > ..........
> >
> > Is an implementation permitted to signal an error for situations in
> > which the consequences are unspecified?
> >
> > Also, is "will not permanently damage the running LISP image, but may
> > signal an error" the proper interpretation of "harmless"?
>
> Doesn't the rider about "no conforming code may depend..." mean that if
> you have to ask, then your code is non-conforming? In which case, just
> go with what your local Lisp does (and don't expect it to work
> elsewhere).
>
> I know this isn't much help - sorry (I'm no expert on Lisp - that's just
> me take on the logic implicit in the quote).
There was a large internal discussion in x3j13 over this.
In my personal opinion, which opinion is no more official than anyone
else's at this point, the effect of "undefined" and "unspecified" are
identical from the point of view of conforming programs.
There was a faction that wanted "unspecified" to mean that the Lisp virtual
machine was not at risk in cases of "unspecified", however, since the Lisp
virtual machine is not relevant to a running computation, but rather the
application's virtual process, and since the effect on that process is not
predictable, this is a distinction largely without meaning of any kind.
The intent of unspecified was that an implementation might specify it.
But then, an implementation might specified something that is undefined, too.
And, having not specified it, even implementation-specific code had better
not rely on it.
Further, there was some attempt to bound the possible ill consequences of
an unspecified problem over an undefined problem, but that's meaningless.
Even non-"errors" can result in catastrophic loss of life in a badly
written program, so surely an unspecified situation can. It simply cannot,
from a formal point of view, be dealt with casually.
Then again, people have had extensive discussions on what it means to assert
that Santa Claus (non existent, as he is) is of different color than a
unicorn. A situation doesn't have to be extant or relevant or whatever in
order to invite the most passionate of discussion.
The best explanation of the description in the spec using different terms is
that it supports possible future work in this area by creating a certain
visible distinction that might want to have meaning attached later. If the
standard is viewed as "work in progress", it makes more sense. (That doesn't
mean the standard IS "work in progress", btw--there doesn't seem much motion
to change the standard. A lot of people seem to want to leave it stable and
instead focus on layered standards.)
Usual disclaimer for remarks such as these: These views are my own and
not necessarily those of any organization or entity that I might be
employed by, a member of, or otherwise affiliated with.
From: Jon K Hellan
Subject: Re: Interpretation of "The consequences are unspecified"
Date:
Message-ID: <87aelisk0o.fsf@parus.parus.no>
Barry Margolin <······@bbnplanet.com> writes:
> In article <·····················@dfw-read.news.verio.net>,
> Joe Marshall <·········@alum.mit.edu> wrote:
> >Wouldn't this allow it to do such things as open files, setq *package*
> >intern symbols, and other sorts of things? Your lisp image might not be
> >`damaged' but these things aren't `harmless'.
>
> Where do you draw the line? If it can't do those things, what do you think
> it *can* do?
Didn't gcc at one point play go for a construct where the effects are
"implementation defined"?
I think it was #pragma.
jon
Jon K Hellan <······@acm.org> writes:
> Didn't gcc at one point play go for a construct where the effects are
> "implementation defined"?
>
> I think it was #pragma.
Dunno about go, but it used to invoke "hack" when it saw #pragma
See http://www.uwsg.indiana.edu/hypermail/linux/kernel/9805.2/0737.html
-dan
From: Kent M Pitman
Subject: Re: Interpretation of "The consequences are unspecified"
Date:
Message-ID: <sfw4sbo3e6e.fsf@world.std.com>
Jon K Hellan <······@acm.org> writes:
> Barry Margolin <······@bbnplanet.com> writes:
>
> > In article <·····················@dfw-read.news.verio.net>,
> > Joe Marshall <·········@alum.mit.edu> wrote:
> > >Wouldn't this allow it to do such things as open files, setq *package*
> > >intern symbols, and other sorts of things? Your lisp image might not be
> > >`damaged' but these things aren't `harmless'.
> >
> > Where do you draw the line? If it can't do those things, what do you think
> > it *can* do?
>
> Didn't gcc at one point play go for a construct where the effects are
> "implementation defined"?
>
> I think it was #pragma.
In CL, "implementation defined" carries with it an expectation that each and
every implementation WILL define the effect. If you didn't have an
implementation-specific manual, this might as well mean "unspecified".
And, as I argued under separate cover, might as well mean "undefined".
I remember discussions with various committee members who have pointed out that
the term "really, really, really ought to" formally means the same as
"doesn't have to if it doesn't want to", though. The point being that a
requirement is a requirement, and anything else is not a requirement, no
matter how strongly hinted. The only reason "should" (as in "should signal")
has a meaning is that it is specially defined not to mean the ordinary
English meaning of "should", but something stonger; the conventional English
meaning of "should" would not have any teeth in CL (nor any standard), not
being a requirement.