Re: Illegal LOOP usage?
- From: Madhu <enometh@xxxxxxxx>
- Date: Wed, 07 Mar 2007 15:07:03 +0530
* Edi Weitz <spamtrap@xxxxxxxxxx> <u1wk15tah.fsf@xxxxxxxxxx> :
| On Wed, 07 Mar 2007 06:34:28 +0530, Madhu <enometh@xxxxxxxx> wrote:
|
|> From which it is inferred that "the actual list being collected be
|> held separately from the variable used in the loop body)."
|>
|> Would that explain it?
|
| Er, no. Thanks for the link, though. I had read the CLHS entry
| myself, but I read it differently. If something is "bound as if
| using a WITH clause," I can modify it within the LOOP's body and
| have the new value available in FINALLY clauses. For what other
| reason would they even mention the WITH clause there?
No, as I read it: as it is bound within a (nested) WITH, your
modification would hold only within that single iteration.
On the next iteration the loop variable would be bound with WITH to
the current-collected-list.
| I see no wording that mandates that the list being collected is held
| separately from the variable used in the loop body. I also think
| that'd be completely counter-intuitive.
Not to me. Let me try again. CLHS 6.3.1 says
During each iteration, the constructs collect and collecting collect
the value of the supplied form into a list. When iteration
terminates, the list is returned. The argument var is set to the
list of collected values; if var is supplied, the loop does not
return the final list automatically. If var is not supplied, it is
equivalent to supplying an internal name for var and returning its
value in a finally clause. The var argument is bound as if by the
construct with.
The behaviour specified is that with a COLLECT ALL values are
collected. There is no provision for mutating that list. The behaviour
specified is (should be) identical whether or not a INTO VAR clause is
specified (as there is no reason to believe otherwise)
The only difference is that when a INTO clause is specified, the loop
does not automatically return the final list.
The behaviour is consistent AFAICT
| Besides, both SBCL and AllegroCL return 11 (and not 10) from this
| loop:
|
| (loop for i from 1 to 10
| maximize i into k
| do (incf k)
| finally (return k))
|
This is consistent. k retains its INCFd value at the end of the last
iteration before execution of the FINAL block.
| To me, the explanation you linked to sounds like an after-the-fact
| justification of the implementation. Unless I see more convincing
| arguments.
Again,
If var is not supplied, it is equivalent to supplying an internal
name for var and returning its value in a finally clause. The var
argument is bound as if by the construct with.
This binding happens on each iteration of loop. I think it is clear
I'm satisfied with things as they are :)
--
Madhu
.
- Follow-Ups:
- Re: Illegal LOOP usage?
- From: Edi Weitz
- Re: Illegal LOOP usage?
- References:
- Illegal LOOP usage?
- From: Edi Weitz
- Re: Illegal LOOP usage?
- From: Madhu
- Re: Illegal LOOP usage?
- From: Edi Weitz
- Illegal LOOP usage?
- Prev by Date: Re: defparameter VS. defvar / setf
- Next by Date: Re: defparameter VS. defvar / setf
- Previous by thread: Re: Illegal LOOP usage?
- Next by thread: Re: Illegal LOOP usage?
- Index(es):
Relevant Pages
|
