gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Loop errors


From: Paul F. Dietz
Subject: Re: [Gcl-devel] Loop errors
Date: Mon, 18 Nov 2002 07:43:09 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Camm Maguire wrote:
Greetings!  Paul, I've cleared some of these.  I'd be most
appreciative if you could elaborate on the correct behavior expected
in the remaining failures.

Failing LOOP tests and explanations:


loop.6.19
loop.6.20

The FOR-AS-HASH clauses should accept a d-var-spec after the FOR
or AS, not just a variable.  The NIL d-var-spec means 'ignore
the value'.  It is accepting the NIL d-var-spec inside larger
compound d-var-specs, but not at the top level.


loop.6.37
loop.6.39

The USING clause of FOR-AS-HASH clauses is supposed to take
a d-var-spec, but is only accepting a symbol (it's not doing
destructuring.)

(These last two errors, and probably some of the others here,
also showed up in other lisps; they're probably also remnants
from the common ancestral LOOP code.)


loop.7.1[567]

According to the page for LOOP, the syntax allows the package
to be omitted.  See the comment before test loop.7.15.  The
syntax is:

for-as-package::= var [type-spec] being {each | the}
                  {symbol | symbols |
                   present-symbol | present-symbols |
                   external-symbol | external-symbols}
                  [{in | of} package]

(Note the square brackets around the last for, indicating it
can be omitted.)

Other lisps also failed to implement this properly.


loop.7.1[89]
loop.7.20

According to the spec (page 6.1.2.1.7), 'If a package that does
not exist is supplied, an error of type package-error is signaled.'
The argument after the OF loop symbol is a package designator,
which can be a string (I need to add tests for package designators
that are characters.)

This may have an effect on the error reporting of package functions.
Recall there was a discussion of whether they should signal a type-error
or a package-error in some situations.  I've modified some of those
tests to accept either kind of error.


loop.7.2[123]

As in loop.6.19 and loop.6.20, the variable in a FOR-AS-PACKAGE
clause is a d-var-spec, and a NIL d-var-spec should indicate the
value is ignored.


loop.8.18
loop.8.23

The implicit (BLOCK NIL ...) around a loop should enclose the entire
loop, including the forms in the initialization section.  See
the examples in section 6.1.2.2.  This is subject to some interpretation.


loop.8.1[89]
loop.8.2[012]

Looks like a bug in the destructuring code.  The NIL is supposed
to make the corresponding part of the list be ignored.


loop.8.error.2
loop.9.1[01]
loop.9.[23][78]
loop.10.9
loop.10.10
loop.10.[35][37]
loop.10.8[56]

Section 6.1.1.7:

"An error of type program-error is signaled (at macro expansion time)
if the same variable is bound twice in any variable-binding clause of
a single loop expression. Such variables include local variables,
iteration control variables, and variables found by destructuring."


loop.11.9

According to the grammar given on the LOOP page, the REPEAT subclause
may appear anywhere in the loop body, not just up in the section
with iteration control subclauses.  This is arguably a spec
error.


loop.12.error.5[012]

Section 6.1.4:

"Using always, never, or thereis in a loop with value accumulation
clauses that are not 'into' causes an error of type program-error to be
signaled (at macro expansion time)."

That is, the collect form needed to be of the form 'collect x into foo'
instead of collecting into the implicit result variable.


        Paul






reply via email to

[Prev in Thread] Current Thread [Next in Thread]