This is what my ACL does:
USER(80): (elt '(1 2) 2)
NIL
As I read the hyperspec, ELT is supposed to signal an error unless the
index is less than the length of the sequence, which in this case it
isn't. Right?
--
Frode Vatvedt Fjeld
"Frode Vatvedt Fjeld" <······@acm.org> wrote in message
···················@dslab7.cs.uit.no...
> This is what my ACL does:
>
> USER(80): (elt '(1 2) 2)
> NIL
In this case, according to the Hyperspec, 2 would not be a "valid sequence
index" because it is not less than the length of the sequence and the
system should signal a type-error.
Corman Lisp signals an error. I'm not at work so I can't check CMUCL or
LispWorks. I'd be interested if it returns nil for any index > 2, as well.
If so, it's probably implementing elt for lists in terms of nth. That
simplifies the coding, but also doesn't raise the proper error.
Good catch...
faa
"Frank A. Adrian" <·······@uswest.net> writes:
> Corman Lisp signals an error. I'm not at work so I can't check CMUCL or
> LispWorks. I'd be interested if it returns nil for any index > 2, as well.
> If so, it's probably implementing elt for lists in terms of nth. That
> simplifies the coding, but also doesn't raise the proper error.
CMUCL 18c and clisp 2000-03-06 throws errors.
--
// John Markus Bj�rndalen
* Frank A Adrian wrote:
> Corman Lisp signals an error. I'm not at work so I can't check CMUCL or
> LispWorks. I'd be interested if it returns nil for any index > 2, as well.
> If so, it's probably implementing elt for lists in terms of nth. That
> simplifies the coding, but also doesn't raise the proper error.
LW signals an error.
Frode Vatvedt Fjeld <······@acm.org> writes:
> This is what my ACL does:
>
> USER(80): (elt '(1 2) 2)
> NIL
>
> As I read the hyperspec, ELT is supposed to signal an error unless the
> index is less than the length of the sequence, which in this case it
> isn't. Right?
I looked at CLHS and didn't see words in ELT's entry that say this.
What words do you think say this?
I think the section being referred to is:
Should signal an error of type type-error if index is not a valid
sequence index for sequence.
According to the definition of valid sequence index in the glossary:
valid sequence index n. (of a sequence) an integer suitable for use to
name an element of the sequence. Such an integer must be greater than or
equal to zero, and must be less than the length of the sequence.
I think this is probably what the original poster meant.
Howard Ding
Kent M Pitman wrote:
>
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > This is what my ACL does:
> >
> > USER(80): (elt '(1 2) 2)
> > NIL
> >
> > As I read the hyperspec, ELT is supposed to signal an error unless the
> > index is less than the length of the sequence, which in this case it
> > isn't. Right?
>
> I looked at CLHS and didn't see words in ELT's entry that say this.
> What words do you think say this?
--
Howard Ding
······@worldnet.att.net
http://math.sunysb.edu/~hading http://thunder.prohosting.com/~hading
Howard Ding <······@worldnet.att.net> writes:
> I think the section being referred to is:
>
> Should signal an error of type type-error if index is not a valid
> sequence index for sequence.
Oh. Oops. I skimmed the text too quickly. Serves me right.
Of course, "should signal" means "must only in high safety". Do we
know the original example was being run in safety=3?
> > Frode Vatvedt Fjeld <······@acm.org> writes:
> >
> > > This is what my ACL does:
> > >
> > > USER(80): (elt '(1 2) 2)
> > > NIL
> > >
> > > As I read the hyperspec, ELT is supposed to signal an error unless the
> > > index is less than the length of the sequence, which in this case it
> > > isn't. Right?
Kent M Pitman <······@world.std.com> writes:
> Of course, "should signal" means "must only in high safety". Do we
> know the original example was being run in safety=3?
I guess I forgot I was reading a standards document, and that things
may not be what they first appear (meaning I'd forgotten to read
section 1.4.2 Error Terminology).
However, ACL returns nil in _all_ cases that I've tried, including
compiled with safety=3 and interpreted (which I'd expect to be a
"safe" mode). So I guess it's a small bug, and I'll report it to
Franz.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Of course, "should signal" means "must only in high safety". Do we
> > know the original example was being run in safety=3?
>
> I guess I forgot I was reading a standards document, and that things
> may not be what they first appear (meaning I'd forgotten to read
> section 1.4.2 Error Terminology).
It's my fault (partly in my role as ANSI CL editor and repeated partly
anew in the production of the HyperSpec, though at that point recognizing
it would have been more tricky) for not making the error terminology
get highlighted as other glossary terms are. I plead "lack of time" as
a mitigating factor. But whatever the excuse, I think the problem isn't
entirely yours. You're suffering from my having done an incomplete job.
> However, ACL returns nil in _all_ cases that I've tried, including
> compiled with safety=3 and interpreted (which I'd expect to be a
> "safe" mode). So I guess it's a small bug, and I'll report it to
> Franz.
That sounds worth doing. Be sure to mention the implementation
version number, in case they've already fixed it.
Frode Vatvedt Fjeld wrote:
>
> This is what my ACL does:
>
> USER(80): (elt '(1 2) 2)
> NIL
>
> As I read the hyperspec, ELT is supposed to signal an error unless the
> index is less than the length of the sequence, which in this case it
> isn't. Right?
I've a few cases where ACL doesn't adhere to the Hyperspec. It happened
when running my ACL code on a CMUCL platform. At first I thought the
difficulties were caused by CMUCL, but after looking at the Hyperspec, I
realized that Allegro had been overly forgiving of my non-spec-observing
code.
-ted
--
··········@att.net
Ted Sandler <··········@worldnet.att.net> writes:
> I've a few cases where ACL doesn't adhere to the Hyperspec. It happened
> when running my ACL code on a CMUCL platform. At first I thought the
> difficulties were caused by CMUCL, but after looking at the Hyperspec, I
> realized that Allegro had been overly forgiving of my non-spec-observing
> code.
Of course, not all non-spec-observing code is required to signal errors.
I bet at least some of those places are ones where ACL is within its rights
to tolerate your error, and CMUCL is merely exercising its equal right to
not tolerate your error. There are a great many situations where errors in
user code leave wide latitude to an implementation, permitting either
"tolerant" or "strict" implementations.