My reading of the CL Hyperspec says that the following
should cause an error:
(setf x (make-array '(100))
(setf y (make-array '(10) :displaced-to x))
(elt y 20)
(because elt is supposed to signal an error if
the index is not valid, and a valid index must
be less than the number of elements in the sequence,
which is 10 in this case.)
Is this a correct reading of the standard?
Paul Dietz
·····@interaccess.com
From: Kent M Pitman
Subject: Re: CL Standards Question (displaced arrays, ELT)t?
Date:
Message-ID: <sfwn2esel1k.fsf@world.std.com>
Paul Dietz <·····@interaccess.com> writes:
>
> My reading of the CL Hyperspec says that the following
> should cause an error:
>
> (setf x (make-array '(100))
> (setf y (make-array '(10) :displaced-to x))
> (elt y 20)
>
> (because elt is supposed to signal an error if
> the index is not valid, and a valid index must
> be less than the number of elements in the sequence,
> which is 10 in this case.)
>
> Is this a correct reading of the standard?
>
> Paul Dietz
> ·····@interaccess.com
Not exactly. Btw, your paraphrase is also not correct; you didn't
replicate the relevant wording enough to keep me from having to look i
up again. ELT is not "supposed to signal an error"; rather it "should
signal an error". In English these are identical in meaning; in
CLHS, the meanings are more structured.
There are a number of technical terms for describing errors and
the phrase "is supposed to" is not one of them but a number of
other phrases have very highly specific technical meaning.
Let's take this opportunity to review those...
Example: x must be an integer.
This means the consequences are undefined if x is not
an integer. It specifies no specific detection or handling.
Example: An error is signaled if unexport is given a symbol
not accessible in the current package
The use of "an error is signaled" or "an error must be signaled"
requires the signaling.
Note: "x must be an integer" and "an error must be signaled
if x is not an integer" are NOT equivalent statements.
Example: + should signal an error of type type-error if
any argument is not of type number.
This means that if the argument is not a number, it MUST
signal IF in high safety mode (see the SAFETY quality of
the OPTIMIZE setting) and MIGHT (OR MIGHT NOT) signal
signal otherwise.
Example: FIND should be prepared to signal an error of type
TYPE-ERROR if its second argument is not a proper
list.
This is like should signal but does not create a
performance-hurting requirement to check what is not
needed. For example,
(FIND 'A '(A B C . D))
can correctly return A even though the sequence is
not a proper sequence because correct execution
does not involve coming up against the dotted-D
to find the A. But
(FIND 'E '(A B C . D))
does come in contact with the dotted pair at the end
and MUST signal that error.
For more info, go to Starting Points in the CLHS at
(http://www.harlequin.com/books/HyperSpec/) and click on "Error
Terminology".
As you can see, the error terminology is rich. But not so
rich that we included the phrases "is upposed to be" or
"really ought to be" or "should be ashamed if it is not"
or a variety of other expressions that were next in line. :-)
Since ELT uses this terminology:
Should be prepared to signal an error of type type-error if
sequence is not a proper sequence.
Should signal an error of type type-error if index is not a
valid sequence index for sequence.
we know immediately that these requirements are only in high
safety mode. In low safety (SAFETY of 2 or less), there is
no error checking or reporting requirement.
Note that an implementation is not required to offer you
high safety; there are permitted to be low-safety lisps.
And any implementation, whether it supports high safety
or not, may default to a lesser safety. But if you try to
explicitly move the safety to 3 where such is not supported,
I'm pretty sure the system is obliged to tell you--I poked
around looking for a refernece to the list claim just now
but didn't find it quickly. Maybe someone else knows.
--Kent
Kent M Pitman wrote:
[ very informative discussion of standards terminology deleted ]
> Note that an implementation is not required to offer you
> high safety; there are permitted to be low-safety lisps.
> And any implementation, whether it supports high safety
> or not, may default to a lesser safety. But if you try to
> explicitly move the safety to 3 where such is not supported,
> I'm pretty sure the system is obliged to tell you--I poked
> around looking for a refernece to the list claim just now
> but didn't find it quickly. Maybe someone else knows.
I just tried this (declared the safety up to 3, speed down
to 0). I know this Lisp does support safety 3.
Having done that, the example below executes without warning
and signals no error.
(declaim (optimize (speed 0) (safety 3) (debug 3) (space 1)))
(defun foo (n)
(let ((x (make-array '(100))))
(loop for i from 0 to 99 do (setf (aref x i) i))
(let ((y (make-array '(10) :displaced-to x)))
(elt y n))))
(compile 'foo)
(foo 20)
Paul
From: Kent M Pitman
Subject: Re: CL Standards Question (displaced arrays, ELT)?
Date:
Message-ID: <sfw90qbt2bg.fsf@world.std.com>
Paul Dietz <·····@interaccess.com> writes:
> I just tried this (declared the safety up to 3, speed down
> to 0). I know this Lisp does support safety 3.
People often set speed to 0 when trying to get high safety but there
is no reason to do so. There may be other useful effects of setting
speed to zero, but making code "more safe" is not one of them. At
least not according to the standard.
> Having done that, the example below executes without warning
> and signals no error.
Sounds like you owe your vendor a bug report.
You're talking about a pretty obscure corner of the language. It's
an easy thing for a vendor to have overlooked, since probably very
little code ever goes there. If you don't report it, it may be
years before someone else has occasion to.