[R6RS] draft statement on safety

[William D Clinger]

Mike wrote:
> >     If a Scheme script is said to be safe, then its execution
> >     cannot go so badly wrong as to crash or to behave in ways
> >     that are inconsistent with the semantics described in this
> >     document, unless said execution first encounters some
> >     implementation restriction or other defect in the
> >     implementation of Scheme that is executing the script.
> 
> Maybe I'm misunderstanding what this says: I'm reading "encounters" as
> roughtly equivalent to "detects".

No, "encounters" was intended to mean "runs across"
or "triggers".  Implementation restrictions are
supposed to raise an exception in safe code, as
should other defects of an implementation, but you
can't count on a defective implementation to do what
it should.  The point of the peculiar language in the
paragraph you quoted is to blame the implementation
for any crash or behavior that is flat-out inconsistent
with the semantics of Scheme, even if the program tries
to do something it shouldn't.

That, to my mind, is the most appropriate definition
of safety for the kind of language described by the
R6RS.  Things can go wrong to the point of raising an
exception, but if they go wrong worse than that in safe
code, then the implementation is at fault, no matter
how brain-dead the program it was executing.

> Now, implementation restrictions
> and defects correspond to condition types we're defining, and I read
> this to imply that an exception must be raised.  Moreover, will
> ((lambda (x) x) (values 1 2)) meet an implementation restriction or a
> defect?

I suppose an implementation could choose to raise an
&implementation-restriction exception, on the grounds
that not allowing ((lambda (x) x) (values 1 2)) to do
something reasonable is indeed a restriction imposed
by the implementation, but I doubt whether many
implementors will view it that way.

I think it is even less likely that an implementor who
chooses not to allow ((lambda (x) x) (values 1 2)) to
do something reasonable (instead of raising an exception)
will view that decision as a defect of his implementation.

So I doubt whether ((lambda (x) x) (values 1 2)) will be
regarded as an implementation restriction or defect by
*anyone*.

> I'm thinking that in Larceny it certainly won't be an
> implementation restriction, so what's left is a defect.

You have created a false dichotomy for yourself.

> Is that the right word to classify it?

No.

Will