Okay, Kenny, you old SOB, here is my final submission to your
obfuscated LOOP contest:
(LOOP FOR WITH =
'(LOOP FOR WITH = '(LOOP FOR WITH) FOR AND IN WITH FOR = = AND FOR
FINALLY =
AND COLLECT FINALLY INTO IF FINALLY
(RETURN
(LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
(LIST 'QUOTE WITH) ELSE COLLECT IN)))
FOR AND IN WITH FOR = = AND FOR FINALLY = AND COLLECT FINALLY INTO IF
FINALLY
(RETURN
(LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
(LIST 'QUOTE WITH) ELSE COLLECT IN)))
In article
<····································@l16g2000hsh.googlegroups.com>,
Kaz Kylheku <········@gmail.com> wrote:
> Okay, Kenny, you old SOB, here is my final submission to your
> obfuscated LOOP contest:
>
> (LOOP FOR WITH =
> '(LOOP FOR WITH = '(LOOP FOR WITH) FOR AND IN WITH FOR = = AND FOR
> FINALLY =
> AND COLLECT FINALLY INTO IF FINALLY
> (RETURN
> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
> (LIST 'QUOTE WITH) ELSE COLLECT IN)))
> FOR AND IN WITH FOR = = AND FOR FINALLY = AND COLLECT FINALLY INTO IF
> FINALLY
> (RETURN
> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
> (LIST 'QUOTE WITH) ELSE COLLECT IN)))
Reminds me of something you could write in PL/I, which didn't reserve
any of its keywords, either:
IF IF =
THEN THEN THEN =
ELSE; ELSE ELSE =
END; END
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Feb 7, 7:53 pm, Barry Margolin <······@alum.mit.edu> wrote:
> Reminds me of something you could write in PL/I, which didn't reserve
> any of its keywords, either:
>
> IF IF =
> THEN THEN THEN =
> ELSE; ELSE ELSE =
> END; END
It is precisely the above that I was thinking of.
I think it's presented in the the Red Dragon book, which I haven't
cracked open in years.
Den Thu, 07 Feb 2008 16:13:34 -0800 skrev Kaz Kylheku:
> Okay, Kenny, you old SOB, here is my final submission to your obfuscated
> LOOP contest:
>
> (LOOP FOR WITH =
> '(LOOP FOR WITH = '(LOOP FOR WITH) FOR AND IN WITH FOR = = AND FOR
> FINALLY =
> AND COLLECT FINALLY INTO IF FINALLY
> (RETURN
> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
> (LIST 'QUOTE WITH) ELSE COLLECT IN)))
> FOR AND IN WITH FOR = = AND FOR FINALLY = AND COLLECT FINALLY INTO IF
> FINALLY
> (RETURN
> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
> (LIST 'QUOTE WITH) ELSE COLLECT IN)))
That is an impressive way to say NIL, but I'm somewhat disappointed that
it's not a quine. Can we expect version Final.1 to fix that bug?
Cheers,
Maciej
On Feb 7, 4:38 pm, Maciej Katafiasz <········@gmail.com> wrote:
> Den Thu, 07 Feb 2008 16:13:34 -0800 skrev Kaz Kylheku:
>
> > Okay, Kenny, you old SOB, here is my final submission to your obfuscated
> > LOOP contest:
>
> > (LOOP FOR WITH =
> > '(LOOP FOR WITH = '(LOOP FOR WITH) FOR AND IN WITH FOR = = AND FOR
> > FINALLY =
> > AND COLLECT FINALLY INTO IF FINALLY
> > (RETURN
> > (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
> > (LIST 'QUOTE WITH) ELSE COLLECT IN)))
> > FOR AND IN WITH FOR = = AND FOR FINALLY = AND COLLECT FINALLY INTO IF
> > FINALLY
> > (RETURN
> > (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
> > (LIST 'QUOTE WITH) ELSE COLLECT IN)))
>
> That is an impressive way to say NIL, but I'm somewhat disappointed that
> it's not a quine.
> Can we expect version Final.1 to fix that bug?
Nope, works on my machine. Your LOOP is obviously broken. :)
Does this return (1 2 3)?
(loop for x = '(1 2 3) for y in x do collect y)
If so, does this also?
(loop for x = '(1 2 3)
for y in x
for z = y
for w = y
collect w)
Kaz Kylheku wrote:
> On Feb 7, 4:38 pm, Maciej Katafiasz <········@gmail.com> wrote:
>
>>Den Thu, 07 Feb 2008 16:13:34 -0800 skrev Kaz Kylheku:
>>
>>
>>>Okay, Kenny, you old SOB, here is my final submission to your obfuscated
>>>LOOP contest:
>>
>>>(LOOP FOR WITH =
>>> '(LOOP FOR WITH = '(LOOP FOR WITH) FOR AND IN WITH FOR = = AND FOR
>>>FINALLY =
>>> AND COLLECT FINALLY INTO IF FINALLY
>>> (RETURN
>>> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
>>> (LIST 'QUOTE WITH) ELSE COLLECT IN)))
>>> FOR AND IN WITH FOR = = AND FOR FINALLY = AND COLLECT FINALLY INTO IF
>>>FINALLY
>>> (RETURN
>>> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP FOR WITH)) COLLECT
>>> (LIST 'QUOTE WITH) ELSE COLLECT IN)))
>>
>>That is an impressive way to say NIL, but I'm somewhat disappointed that
>>it's not a quine.
>>Can we expect version Final.1 to fix that bug?
>
>
> Nope, works on my machine. Your LOOP is obviously broken. :)
Mine, too, obviously. I got nil.
>
> Does this return (1 2 3)?
>
> (loop for x = '(1 2 3) for y in x do collect y)
Error: Compound form expected, but found COLLECT.
Current LOOP context: DO COLLECT Y.
Lose the do, then you can get the expected NIL.
>
> If so, does this also?
>
> (loop for x = '(1 2 3)
> for y in x
> for z = y
> for w = y
> collect w)
NIL, of course.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Den Thu, 07 Feb 2008 17:48:59 -0800 skrev Kaz Kylheku:
>> That is an impressive way to say NIL, but I'm somewhat disappointed
>> that it's not a quine.
>> Can we expect version Final.1 to fix that bug?
>
> Nope, works on my machine. Your LOOP is obviously broken. :)
>
> Does this return (1 2 3)?
>
> (loop for x = '(1 2 3) for y in x do collect y)
A compound form was expected, but collect found.
current LOOP context: do collect y.
[Condition of type sb-int:simple-program-error]
> If so, does this also?
>
> (loop for x = '(1 2 3)
> for y in x
> for z = y
> for w = y
> collect w)
This one gives NIL. SBCL 1.0.10 (I guess I should rebuild a newer version
one of these days).
Cheers,
Maciej
On Feb 7, 6:35 pm, Maciej Katafiasz <········@gmail.com> wrote:
> Den Thu, 07 Feb 2008 17:48:59 -0800 skrev Kaz Kylheku:
>
> >> That is an impressive way to say NIL, but I'm somewhat disappointed
> >> that it's not a quine.
> >> Can we expect version Final.1 to fix that bug?
>
> > Nope, works on my machine. Your LOOP is obviously broken. :)
>
> > Does this return (1 2 3)?
>
> > (loop for x = '(1 2 3) for y in x do collect y)
>
> A compound form was expected, but collect found.
Oops, I cut and pasted the wrong form, something half-edited from
earlier in my REPL session. Of course DO does not take a clause, but
is a way of turning a sequence of normal Lisp forms into an
unconditional clause; note that DO is not used at all in my obfuscated
LOOP, so why would I have it in a simplified test case.
Try:
(loop for x = '(1 2 3) for y in x collect y)
If that yields NIL, it shows that the broken LOOP isn't propagating
the '(1 2 3) from the first FOR to the second.
If it was for x = '(1 2 3) AND y in x then it would make sense.
The previous value of X is NIL in the first iteration, and so Y gets
that.
> > (loop for x = '(1 2 3)
> > for y in x
> > for z = y
> > for w = y
> > collect w)
>
> This one gives NIL. SBCL 1.0.10 (I guess I should rebuild a newer version
> one of these days).
Maybe the workaround is to change the first FOR to a WITH. See, nobody
should use FOR this way; I intended a variable initialization, not a
repeated assignment of the same value to the variable on each
iteration.
(LOOP WITH AND =
'(LOOP WITH AND = '(LOOP WITH AND = DNA) FOR WITH IN AND FOR = = AND
FOR
FINALLY = WITH COLLECT FINALLY INTO IF FINALLY
(RETURN
(LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP WITH AND = DNA)) COLLECT
(LIST 'QUOTE AND) ELSE COLLECT IN)))
FOR WITH IN AND FOR = = AND FOR FINALLY = WITH COLLECT FINALLY INTO
IF FINALLY
(RETURN
(LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP WITH AND = DNA)) COLLECT
(LIST 'QUOTE AND) ELSE COLLECT IN)))
Kaz Kylheku wrote:
> On Feb 7, 6:35 pm, Maciej Katafiasz <········@gmail.com> wrote:
>
>>Den Thu, 07 Feb 2008 17:48:59 -0800 skrev Kaz Kylheku:
>>
>>
>>>>That is an impressive way to say NIL, but I'm somewhat disappointed
>>>>that it's not a quine.
>>>>Can we expect version Final.1 to fix that bug?
>>
>>>Nope, works on my machine. Your LOOP is obviously broken. :)
>>
>>>Does this return (1 2 3)?
>>
>>> (loop for x = '(1 2 3) for y in x do collect y)
>>
>>A compound form was expected, but collect found.
>
>
> Oops,
Oops? Ooops?!!! I spend 300,000 miiliseconds out of what little remains
of my life on a cut and paste error and all you can say is frickin oops?
Well, as long as you do not...
> Try:
Turn loose the hounds.
>
> (loop for x = '(1 2 3) for y in x collect y)
Why are you exploring deliberately retarded forms in a DSL? Now y'all
know why I gotta get outtahere.
>
> If that yields NIL, it shows that the broken LOOP isn't propagating
> the '(1 2 3) from the first FOR to the second.
>
> If it was for x = '(1 2 3) AND y in x then it would make sense.
> The previous value of X is NIL in the first iteration, and so Y gets
> that.
>
>
>>> (loop for x = '(1 2 3)
>>> for y in x
>>> for z = y
>>> for w = y
>>> collect w)
>>
>>This one gives NIL. SBCL 1.0.10 (I guess I should rebuild a newer version
>>one of these days).
>
>
> Maybe the workaround is to change the first FOR to a WITH.
Ok, help me here. You concede now that you haven't the slightest clue
about LOOP and you are trying to preach to us and telling us to run
stuff to see what it does in our implementations when you are just
publishing the droolings of a newborn??!!! Jeez...
Well, you do get points for calling the correction of your asinity a
"workaround" -- frickin priceless -- Google knows I love a fine brass pair.
"Workaround"?????????????? PWUAHAHAHAHHHAHHAHAHAH.
2+2=5
Hang on, I have a workaround: 4. Whew! Gotta be a genius prize in there
for that save!
> See, nobody
> should use FOR this way; I intended a variable initialization, not a
> repeated assignment of the same value to the variable on each
> iteration.
You are the man! You seamlessly turn your ignorance into a lecture
series on how loop works! See, nobody should be as dense as me...
Meanwhile, a simple "Oh, cripes, my bad. What a 'tard. Sorry for the
noise." would have endeared you to everyone. I would have unleashed the
hounds and they'd be licking your face!
>
> (LOOP WITH AND =
> '(LOOP WITH AND = '(LOOP WITH AND = DNA) FOR WITH IN AND FOR = = AND
> FOR
> FINALLY = WITH COLLECT FINALLY INTO IF FINALLY
> (RETURN
> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP WITH AND = DNA)) COLLECT
> (LIST 'QUOTE AND) ELSE COLLECT IN)))
> FOR WITH IN AND FOR = = AND FOR FINALLY = WITH COLLECT FINALLY INTO
> IF FINALLY
> (RETURN
> (LOOP FOR IN IN IF WHEN (EQUAL IN ''(LOOP WITH AND = DNA)) COLLECT
> (LIST 'QUOTE AND) ELSE COLLECT IN)))
Boy. No wolf. Please note unresponsiveness.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Thu, 7 Feb 2008 20:33:58 -0800 (PST), Kaz Kylheku <········@gmail.com> wrote:
> Try:
>
> (loop for x = '(1 2 3) for y in x collect y)
>
> If that yields NIL, it shows that the broken LOOP isn't propagating
> the '(1 2 3) from the first FOR to the second.
My understanding of the LOOP specification is that your expectation is
wrong. Amongst other things, in 6.1.1.8 it explicitly says that the
rules in 3.6 have to be obeyed, specifically the one about list
traversal. If the loop above behaved as you'd expect in a conforming
implementation, how would you expect
(loop for i from 5 downto 2
for x = (loop for j below i collect j)
for y in x
collect y)
to behave? I think the Lisp you're using is broken.
FWIW, LispWorks also returns NIL for your example and that seems to be
right to me.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Feb 7, 8:51 pm, Edi Weitz <········@agharta.de> wrote:
> On Thu, 7 Feb 2008 20:33:58 -0800 (PST), Kaz Kylheku <········@gmail.com> wrote:
> > Try:
>
> > (loop for x = '(1 2 3) for y in x collect y)
>
> > If that yields NIL, it shows that the broken LOOP isn't propagating
> > the '(1 2 3) from the first FOR to the second.
>
> My understanding of the LOOP specification is that your expectation is
> wrong. Amongst other things, in 6.1.1.8 it explicitly says that the
> rules in 3.6 have to be obeyed, specifically the one about list
> traversal.
That talks about some destructive modification of CDR fields, which we
don't have going on at all.
I'm modifying the variable X. Except I'm ``modifying'' it by assigning
exactly the same value to it (same literal object, EQ!).
Even if the FOR Y = X clause were to work by stepping a hidden integer
K from 0, and evaluating (NTH K X) at every iteration to pull out the
value, it should still work right.
The problem with these implementations that return NIL is that they
use the old value of X before it is initialized. And that contravenes
the idea that the FOR clauses are ordered.
They are ordered because stuff like this works:
(loop for linear below 10
for quadratic = linear then (+ quadratic linear)
collect quadratic)
=> (0 1 3 6 10 15 21 28 36 45)
If the "FOR QUADRATIC =" clause behaved like our "FOR Y IN X", it
should access a NIL value of LINEAR in the first iteration, right? But
it doesn't; it retrieves the value 0, because the clauses are done in
series.
> If the loop above behaved as you'd expect in a conforming
> implementation, how would you expect
>
> (loop for i from 5 downto 2
> for x = (loop for j below i collect j)
> for y in x
> collect y)
>
> to behave?
My interpretation:
In the first iteration, i would get the value 5. Then x would get the
value of the expression (loop for j below i collect j), in other words
(0 1 2 3 4). Then y would be set up to iterate over this (0 1 2 3 4)
list. On the subsequent iterations, the value of x would change to (0
1 2 3), but that's of no consequence, since y steps over the original
list, and new values of X are simply ignored. Termination comes from
the first clause, when i reaches value 2, and so y manages to iterate
only over (0 1 2 3), which is what is collected.
> I think the Lisp you're using is broken.
The machine where I'm trying all this has an installation of CLISP
2.38.
Let's see what it does with your example:
[1]> (loop for i from 5 downto 2
for x = (loop for j below i collect j)
for y in x
collect y)
(0 1 2 3)
Bingo; CLISP 2.38 conforms to the Kaz model. I should try the bleeding
edge version; maybe they did something to screw up loop in the last
two years.
> FWIW, LispWorks also returns NIL for your example and that seems to be
> right to me.
They're just stealing broken code from SBCL. :)
But seriously, what is their macroexpansion?
ACL also returns NIL (I'm trying via their live telnet REPL). ACL's
expansion is:
(BLOCK NIL
(LET ((X NIL))
(LET ((Y NIL) (#:G17 X)) (DECLARE (IGNORABLE Y) (TYPE L IST #:G17))
(WITH-LOOP-LIST-COLLECTION-HEAD (#:G18 #:G19)
(TAGBODY NEXT-LOOP (LOOP-REA LLY-DESETQ X '(1 2 3))
(WHEN (ENDP #:G17) (GO END-LOOP)) (LOOP-REALLY-DESET Q Y (CAR
#:G17))
(LOOP-REALLY-DESETQ #:G17 (CDR #:G17))
(LOOP-COLLECT-RPLACD (#:G18 #:G19) (LIST Y)) (GO NEXT-LOOP) END-
LOOP
(RETURN-FROM NIL (LOOP-COLLECT-ANSWER #:G18)))))))
This #:G17 gensym is used which holds a copy of the original X.
Aha, what this is saying is that the expression in a FOR IN is
special. It is evaluated outside of the normal order of the FOR
expressions, prior to the loop.
The value of X is reduced and assigned to a gensym outside of the loop
itself.
Let's make this super clear:
(loop for x = '(1 2 3) for y in x for z = x do (return x y z))
But this is inconsistent with the way variable references work in the
other for clauses! If I use ACL to evaluate:
(loop for x = 42 for y = x do (return y))
I simply get 42. Macroexpansion:
(BLOCK NIL
(LET ((X NIL))
(LET ((Y NIL))
(TAGBODY
EXCL::NEXT-LOOP
(EXCL::LOOP-REALLY-DESETQ X 42)
(EXCL::LOOP-REALLY-DESETQ Y X)
(RETURN Y)
EXCL::END-LOOP))))
See? Straightforward sequential processing.
So in the clause "for y = x", the way x is referenced is different
from the way it is referenced in "for y in x".
That's the problem. Inconsistent lexical reference semantics from two
very similar contexts!
What a bagbiter.
Den Fri, 08 Feb 2008 05:51:34 +0100 skrev Edi Weitz:
> My understanding of the LOOP specification is that your expectation is
> wrong. Amongst other things, in 6.1.1.8 it explicitly says that the
> rules in 3.6 have to be obeyed, specifically the one about list
> traversal. If the loop above behaved as you'd expect in a conforming
> implementation, how would you expect
>
> (loop for i from 5 downto 2
> for x = (loop for j below i collect j)
> for y in x
> collect y)
>
> to behave? I think the Lisp you're using is broken.
Mine surely is, the above snippet results in NIL in SBCL. And (0 1 2 3)
in Clisp. Given that the result I expected was (0 1 2 3 4 0 1 2 3 0 1 2 0
1), it seems that both are broken, albeit in different ways. And adapting
the testcases to ITERATE uncovered some bugs in the same vein as well.
Fun times, bugreports ahoy.
Cheers,
Maciej
On Feb 8, 5:12 am, Maciej Katafiasz <········@gmail.com> wrote:
> Den Fri, 08 Feb 2008 05:51:34 +0100 skrev Edi Weitz:
>
> > My understanding of the LOOP specification is that your expectation is
> > wrong. Amongst other things, in 6.1.1.8 it explicitly says that the
> > rules in 3.6 have to be obeyed, specifically the one about list
> > traversal. If the loop above behaved as you'd expect in a conforming
> > implementation, how would you expect
>
> > (loop for i from 5 downto 2
> > for x = (loop for j below i collect j)
> > for y in x
> > collect y)
>
> > to behave? I think the Lisp you're using is broken.
>
> Mine surely is, the above snippet results in NIL in SBCL. And (0 1 2 3)
> in Clisp. Given that the result I expected was (0 1 2 3 4 0 1 2 3 0 1 2 0
> 1),
LOOP is just dumb looping; it's not intended to implement anything
remotely resembling Icon-like generators, and it doesn't do implicit
nesting.
The FOR clauses work in parallel across the iterations. That is to
stay, each clause is called upon to step exactly once and produce the
next value for its variable.
The FOR Y IN X doesn't mean ``iterate in a inner loop over every
member of the list that X contains in this iteration of the outer
loop''.
If you want two nested loops, you have to write two LOOP's and nest
them. So noe way to get the above result is:
(loop for i from 5 downto 2
appending (loop for j below i collect j))
Maciej Katafiasz <········@gmail.com> writes:
> Den Fri, 08 Feb 2008 05:51:34 +0100 skrev Edi Weitz:
>
> > My understanding of the LOOP specification is that your expectation is
> > wrong. Amongst other things, in 6.1.1.8 it explicitly says that the
> > rules in 3.6 have to be obeyed, specifically the one about list
> > traversal. If the loop above behaved as you'd expect in a conforming
> > implementation, how would you expect
> >
> > (loop for i from 5 downto 2
> > for x = (loop for j below i collect j)
> > for y in x
> > collect y)
> >
> > to behave? I think the Lisp you're using is broken.
>
> Mine surely is, the above snippet results in NIL in SBCL. And (0 1 2 3)
> in Clisp. Given that the result I expected was (0 1 2 3 4 0 1 2 3 0 1 2 0
> 1), it seems that both are broken, albeit in different ways. And adapting
> the testcases to ITERATE uncovered some bugs in the same vein as well.
> Fun times, bugreports ahoy.
Are you aiming at some type of "comprehension"? For example, like
this?
(all y :suchthat
(i :in (the-range 5 2 :by -1))
(x (the-range 0 (1- i)))
(y :in x))
(0 1 2 3 4 0 1 2 3 0 ...)
(pprint *)
(0 1 2 3 4 0 1 2 3 0 1 2 0 1)
The ALL operation is comprehension on steroids (the above is just a
very minor example...) Of course, you may be wondering "WTF is the
'ALL' operation". I keep debating on whether to release all this
stuff...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
* Kaz Kylheku Wrote on Thu, 7 Feb 2008 17:48:59 -0800 (PST):
| Nope, works on my machine. Your LOOP is obviously broken. :)
|
| Does this return (1 2 3)?
|
| (loop for x = '(1 2 3) for y in x do collect y)
Your LOOP fu is lacking. If you wanted this to return '(1 2 3)
you should have written:
(loop with x = '(1 2 3) for y in x collect y)
Lets look at what you wrote:
(loop for x = '(1 2 3) for y in x do collect y)
There are two for clauses: the first one is a
"6.1.2.1.4 The for-as-equals-then subclause"
for-as-equals-then::= var [type-spec] = form1 [then form2]
"In the for-as-equals-then subclause the for or as construct initializes
the variable var by setting it to the result of evaluating form1 on the
first iteration, then setting it to the result of evaluating form2 on
the second and subsequent iterations. If form2 is omitted, the
construct uses form1 on the second and subsequent iterations. The loop
keywords = and then serve as valid prepositions in this syntax. This
construct does not provide any termination tests."
So X will get initialized to '(1 2 3) at the begining of each iteration.
However BEFORE the first iteration it is bound to NIL. [For example See
(loop for a = 10 initially (princ x) repeat 2 do (princ ".."))]
The second is for clause is a
"6.1.2.1.2 The for-as-in-list subclause"
for-as-in-list::= var [type-spec] in form1 [by step-fun]
"In the for-as-in-list subclause, the for or as construct iterates over
the contents of a list. It checks for the end of the list as if by
using endp. The variable var is bound to the successive elements of the
list in form1 before each iteration. At the end of each iteration, the
function step-fun is applied to the list; the default value for
step-fun is cdr. The loop keywords in and by serve as valid
prepositions in this syntax. The for or as construct causes termination
when the end of the list is reached."
So Y will be initialized to successive elements of X before each
iteration. But what is X ?
"6.1.1.6 Order of Execution"
"With the exceptions listed below, clauses are executed in the loop
body in the order in which they appear in the source. Execution is
repeated until a clause terminates the loop or until a return, go, or
throw form is encountered which transfers control to a point outside of
the loop. The following actions are exceptions to the linear order of
execution:
* All variables are initialized first, regardless of where the establishing
clauses appear in the source. The order of initialization follows the
order of these clauses."
So X is initialized to NIL before entering entering the first
iteration. [vide "6.1.2.2 Local Variable Initializations"]
When does the loop terminate?
"6.1.2.1 Iteration Control"
"The for and as clauses iterate by using one or more local loop
variables that are initialized to some value and that can be modified
or stepped[1] after each iteration. For these clauses, iteration
terminates when a local variable reaches some supplied value or when
some other loop clause terminates iteration."
The first for clause will never terminate. The second for clause
terminates when there are no more elements to iterate over, as per
6.1.2.2 above when the list it is iterating over is empty.
Before the first iteration is entered, but after the variables have been
initiallzed, when we determine that this list is empty.
SO the loop is never entered. And returns NIL as a consequence.
I'd like to emphasise that there is no ambiguity in LOOP, the perceived
ambiguity comes from people expecting some behaviour without
understanding the well specified execution model.
--
Madhu
PS: If your goal was to return (1 2 3) you should not even start
considering this form of LOOP. Even when what you wrote is translated to
DO* (do* ((x '(1 2 3) '(1 2 3))
(xtemp x (cdr xtemp))
(y (car x))
(ret))
((null xtemp) (reverse ret))
(push y ret))
all you can hope is for (1 1 1)
On Feb 7, 7:38 pm, Madhu <·······@meer.net> wrote:
> If you wanted this to return '(1 2 3) you should have written:
>
> (loop with x = '(1 2 3) for y in x collect y)
But the point is that
(loop for x = '(1 2 3) for y in x collect y)
/does/ return (1 2 3) for me. I suspected that this is the cause of
the problem, which is why I presented that test case. (Though I
fumbled with that spurious DO).
> * All variables are initialized first, regardless of where the establishing
> clauses appear in the source. The order of initialization follows the
> order of these clauses."
>
> So X is initialized to NIL before entering entering the first
> iteration.
Indeed yes, so what?
> The first for clause will never terminate. The second for clause
> terminates when there are no more elements to iterate over, as per
> 6.1.2.2 above when the list it is iterating over is empty.
X isn't the empty list any longer, because the first clause, FOR X =
'(1 2 3), assigns a value to X. This clause is not combined with the
second FOR Y clause using AND, so they do not work in parallel.
I understand that X is a local variable that starts out NIL. The first
FOR must change that by giving it a value.
Now, if I had
FOR X = '(1 2 3) AND Y IN X
then you would have a case. Now they are parallel, and so Y iterates
using the value of X that existed before the assignment of '(1 2 3),
the initial NIL. Thus the FOR Y IN clause instantly terminates and the
loop is dead on arrival.
> I'd like to emphasise that there is no ambiguity in LOOP, the perceived
> ambiguity comes from people expecting some behaviour without
> understanding the well specified execution model.
Right, and ``People'' includes the ones implementing LOOP, apparently,
which is why we are getting different answers for some perfectly
innocuous code that ought to be portable.
It looks like LOOP is harder to get right than a lot of other parts of
Common Lisp! LOOP is historically a source of portability bugs.
> --
> Madhu
>
> PS: If your goal was to return (1 2 3) you should not even start
> considering this form of LOOP.
>
> Even when what you wrote is translated to
> DO* (do* ((x '(1 2 3) '(1 2 3))
> (xtemp x (cdr xtemp))
> (y (car x))
This is not how FOR IN works. It captures the value of the list
expression once, and then steps over /that/ list object, regardless of
what happens to the value of that original expression.
What you want above is:
(Y (CAR XTEMP))
You must use your hidden list iteration variable to set up the
successive values for Y, not make repeated references to the X
variable.
The logic you are describing has no hope of working; it's just
extracting (CAR X) on every iteration, and X doesn't change.
> (ret))
> ((null xtemp) (reverse ret))
See, why are you using the hidden iteration variable XTEMP to figure
out when the list iteration ends, but using (CAR X) to actually pull
out the value?
The logic is inconsistent.
> (push y ret))
> all you can hope is for (1 1 1)
Nope. For instance:
(let ((list '(1 2 3)))
(loop for x in list collecting x do pop list))
should still produce (1 2 3), even though LIST changes throughout the
loop. The x variable iterates over the object that was initially
produced by LIST.
* Kaz Kylheku Wrote on Thu, 7 Feb 2008 21:03:21 -0800 (PST):
| On Feb 7, 7:38 pm, Madhu
|> If you wanted this to return '(1 2 3) you should have written:
|>
|> (loop with x = '(1 2 3) for y in x collect y)
|
| But the point is that
|
| (loop for x = '(1 2 3) for y in x collect y)
|
| /does/ return (1 2 3) for me. I suspected that this is the cause of
| the problem, which is why I presented that test case. (Though I
| fumbled with that spurious DO).
This must considered merely to be an artifact of your implementation,
you should not make an inference on how LOOP *should* behave from this
behaviour.
|> * All variables are initialized first, regardless of where the establishing
|> clauses appear in the source. The order of initialization follows the
|> order of these clauses."
|>
|> So X is initialized to NIL before entering entering the first
|> iteration.
|
| Indeed yes, so what?
There are two `initializations' in execution of LOOP, [as I tried to make
clear].
One: INITIALLY. All variables are initialized at the beginning --- but
before staring the first iteration. the INITIALLY clause is executed
after this phase.
Two: At beginning of each iteration. All variables in the FOR clauses
are initialized in this phase.
(loop with x = 10 initially (princ x) repeat 2 do (dummy))
=> prints 10.
(loop for x = 10 initially (princ x) repeat 2 do (dummy))
=> prints NIL
ONLY WITH variables are initialized before start of first iteration. FOR
iterations are bound to NIL.
But this is already clear to you
|> The first for clause will never terminate. The second for clause
|> terminates when there are no more elements to iterate over, as per
|> 6.1.2.2 above when the list it is iterating over is empty.
|
| X isn't the empty list any longer, because the first clause, FOR X =
| '(1 2 3), assigns a value to X. This clause is not combined with the
| second FOR Y clause using AND, so they do not work in parallel.
I cited the reference to show it is initialized to (1 2 3) ONLY during
the beginning of the first iteration.
But the termination test for the 2nd for loop kicks in BEFORE that!
Which is why the loop is never entered.
| I understand that X is a local variable that starts out NIL. The first
| FOR must change that by giving it a value.
|
| Now, if I had
|
| FOR X = '(1 2 3) AND Y IN X
|
| then you would have a case. Now they are parallel, and so Y iterates
| using the value of X that existed before the assignment of '(1 2 3),
| the initial NIL. Thus the FOR Y IN clause instantly terminates and the
| loop is dead on arrival.
No no no! LOOP FOR X = '(1 2 3) AND Y IN X is just wrong syntax. It is
not allowed by LOOP. your mplementation is horrible if it lets it
through. The two `for' clauses being connected are different. the
second clause is a for-as-in-list clause.
The only reason it would terminate would be the same. INITIALLY: X NIL Y
NIL. The termination test passes, before the first iteration of the
loop (when the for-as-is-clause variable can be initialized) is even
entered.
|> I'd like to emphasise that there is no ambiguity in LOOP, the perceived
|> ambiguity comes from people expecting some behaviour without
|> understanding the well specified execution model.
|
| Right, and ``People'' includes the ones implementing LOOP, apparently,
| which is why we are getting different answers for some perfectly
| innocuous code that ought to be portable.
|
| It looks like LOOP is harder to get right than a lot of other parts of
| Common Lisp! LOOP is historically a source of portability bugs.
That may be a fact, but I think it tells more on the implementors
ability/taste than the standard.
|> PS: If your goal was to return (1 2 3) you should not even start
|> considering this form of LOOP.
|>
|> Even when what you wrote is translated to
|> DO* (do* ((x '(1 2 3) '(1 2 3))
|> (xtemp x (cdr xtemp))
|> (y (car x))
|
| This is not how FOR IN works. It captures the value of the list
| expression once, and then steps over /that/ list object, regardless of
| what happens to the value of that original expression.
Yes, My mistake I meant (CAR XTEMP).
| What you want above is:
|
| (Y (CAR XTEMP))
|
| You must use your hidden list iteration variable to set up the
| successive values for Y, not make repeated references to the X
| variable.
|
| The logic you are describing has no hope of working; it's just
| extracting (CAR X) on every iteration, and X doesn't change.
|
|> (ret))
|> ((null xtemp) (reverse ret))
|
| See, why are you using the hidden iteration variable XTEMP to figure
| out when the list iteration ends, but using (CAR X) to actually pull
| out the value?
|
| The logic is inconsistent.
But This was not even meant to be an accurate translation of your
[wrong]example. It was meant to illustrate a point. And it is easily
illustrated now :)
You said yourself that Y is meant ``capture the value of the list
expression once, and then step over /that/ list object, regardless of
what happens to the value of that original expression.''
Now, this happens but it happens BEFORE X is initialized to '(1 2 3) in
the for-as-then clause. It HAS to happen then, and not on the first
iteration, [it is this implausibility of this scenario i wished to show
in the DO* example, but no point continuing on a wrong example]
|
| (let ((list '(1 2 3)))
| (loop for x in list collecting x do pop list))
|
| should still produce (1 2 3), even though LIST changes throughout the
| loop. The x variable iterates over the object that was initially
| produced by LIST.
Yes
--
Madhu
On Feb 7, 10:19 pm, Madhu <·······@meer.net> wrote:
> * Kaz Kylheku Wrote on Thu, 7 Feb 2008 21:03:21 -0800 (PST):
> | Now, if I had
> |
> | FOR X = '(1 2 3) AND Y IN X
> |
> | then you would have a case. Now they are parallel, and so Y iterates
> | using the value of X that existed before the assignment of '(1 2 3),
> | the initial NIL. Thus the FOR Y IN clause instantly terminates and the
> | loop is dead on arrival.
>
> No no no! LOOP FOR X = '(1 2 3) AND Y IN X is just wrong syntax. It is
> not allowed by LOOP. your mplementation is horrible if it lets it
> through.
> The two `for' clauses being connected are different. the
> second clause is a for-as-in-list clause.
It isn't wrong syntax. But it's not treated how I described, either.
In fact, it's an unbound variable (a semantic problem, occuring once
the syntax is accepted and translated, and the expansion is
evaluated).
The FOR-AS clauses must precede the other body clauses because they
establish bindings for variables used in those clauses. One FOR clause
also establishes bindings for a following FOR clause. Here, the use of
X is not established by any lexically prior clause.
But it's not wrong syntax due to the subclauses being different kinds.
The LOOP grammar does generates heterogeneous FOR clauses, and there
is no other constraint specified to rule them out.
* I Wrote on Fri, 08 Feb 2008 11:49:27 +0530:
|
| There are two `initializations' in execution of LOOP, [as I tried to make
| clear].
|
| One: INITIALLY. All variables are initialized at the beginning --- but
| before staring the first iteration. the INITIALLY clause is executed
| after this phase.
|
| Two: At beginning of each iteration. All variables in the FOR clauses
| are initialized in this phase.
I admit that it can be admitted that there is an ambiguity here, so I'll
offer my previous messages as rebranded as humble suggestions at an
interpretation. :)
--
Madhu
On Feb 7, 11:21 pm, Madhu <·······@meer.net> wrote:
> * I Wrote on Fri, 08 Feb 2008 11:49:27 +0530:
> |
> | There are two `initializations' in execution of LOOP, [as I tried to make
> | clear].
> |
> | One: INITIALLY. All variables are initialized at the beginning --- but
> | before staring the first iteration. the INITIALLY clause is executed
> | after this phase.
> |
> | Two: At beginning of each iteration. All variables in the FOR clauses
> | are initialized in this phase.
>
> I admit that it can be admitted that there is an ambiguity here, so I'll
> offer my previous messages as rebranded as humble suggestions at an
> interpretation. :)
In fact, there is no ambiguity. Watch this!
Exhibit A:
6.1.2.1 Iteration Control
[ ... ] All variables are initialized in the loop prologue.
Thus if we have ``for x = '(1 2 3)'', it is initialized in the
prologue, and the initial value is '(1 2 3).
[ ... ] The for and as clauses iterate by using one
or more local loop variables that are initialized
to some value and that can be modified or stepped after
each iteration.
Reinforces the idea that the storage of '(1 2 3) in X is an
initialization. X has an initial value, and it is not NIL, but '(1 2
3). Variables are stepped AFTER an iteration!
(However, this is contradicted somewhat by
6.1.2.1.4 The for-as-equals-then subclause
In the for-as-equals-then subclause the for or as construct
initializes the variable var by setting it to the result
of evaluating form1 on the first iteration ...
What's this? Initialization is not assignment! Only in very informal
writing can you say that a variable is initialized by setting. This
kind of blurring doesn't belong in a programming language standard.
Does this mean that the for-as-equals-then variables are not
initialized in the prologue? I don't think so. The word initialize is
used, and initialization of all variables takes place in the prologue.
What is the prologue?
6.1.1.4 Expanding Loop Forms
[ ... ]
The loop prologue contains forms that are executed before
iteration begins, such as any automatic variable
initializations prescribed by the variable clauses,
along with any initially clauses in the order they
appear in the source.
How is the prologue related to the loop body?
[ ... ]
The loop body contains those forms that are executed
during iteration, including application-specific
calculations, termination tests, and variable stepping.
So, initialization in the prologue; termination tests in the body!
And then we have this:
6.1.1.6 Order of Execution
[ ... ]
All variables are initialized first, regardless of where
the establishing clauses appear in the source. The order
of initialization follows the order of these clauses.
Thus if we have X = '(1 2 3) and Y IN X, there are two
initializations. X is initialized to (1 2 3) and Y is initialized to
(FIRST X). The initializations follow the order of the clauses. Y
cannot be initialized to (FIRST X) where X is the empty list NIL,
because X is initialized by a clause which precedes.
[ ... ]
* Iteration control clauses implicitly perform
the following actions:
-- initialize variables;
-- step variables, generally between each
execution of the loop body;
-- perform termination tests, generally
just before the execution of the loop body.
The termination test for the Y IN X list iteration cannot be performed
before the variables are initialized. It must be performed just before
the loop body is executed---in other words, just before all those
other clauses that are placed after the FOR-AS clauses.
Initialize or step the variables, then test everything for
termination. This is perfectly clear.
Anything else?
6.1.1.2 Iteration Control
[ ... ]
If multiple iteration clauses are used to control iteration,
variable initialization and stepping occur sequentially by
default.
Again, initialization is sequential.
Now for some holes:
- it is not specified that the variable in a FOR-AS-IN-LIST is
initialized. Only that it's ``bound'' to the successive values of the
list (6.1.2.1.2). Unfortunate language, yet again! The word bind is
being misused. A variable binds a symbol to a memory location, which
holds a value. The variable denotes that memory location, not the
value. Stepping a loop variable means overwriting the memory location,
not creating a new binding. Argh. If we look at FOR-AS-IN-LIST it in
the most abstract way, FOR I IN '(A B C) means that I is intialized to
A before the first iteration, and then is to be stepped to B, and then
stepped C. This is how it fits into the high level model of
initialization and stepping.
- there is ambiguity regarding the relatinoship between termination
tests and the loop body. 6.1.1.4 claims that the loop body contains
termination tests. (I quoted that part already). But 6.1.1.6 Order of
Execution says that termination tests are done just before the
execution of the loop body! (Quoted that already too). So terminatino
tests are either in the body or not. Of course, the body has to
include everything that is repeated, so 6.1.1.4 is right. There is
nothing but the prologue, the body and the epilogue. So 6.1.1.6 should
say that the termination tests are done just before the remainder of
the loop body. The termination tests /are/ the first thing to be done
in the loop body; variable stepping is done at the end of an
iteration, and initializations are in the prologue!
* Kaz Kylheku Wrote on Fri, 8 Feb 2008 00:18:39 -0800 (PST):
|
| In fact, there is no ambiguity. Watch this!
If you say so :)
|
| 6.1.2.1.4 The for-as-equals-then subclause
|
| In the for-as-equals-then subclause the for or as construct
| initializes the variable var by setting it to the result of
| evaluating form1 on the first iteration ...
|
| What's this? Initialization is not assignment! Only in very informal
| writing can you say that a variable is initialized by setting. This
| kind of blurring doesn't belong in a programming language standard.
| Does this mean that the for-as-equals-then variables are not
| initialized in the prologue? I don't think so. The word initialize is
| used, and initialization of all variables takes place in the prologue.
I think this is the crux of the problem. Ex post-facto rationalization
of the behaviours implementations other than CLISP suggests that the
problem isn't about FOR-AS-IN-LIST at all[1], but about when the
implementation decides to initialize (i.e. assign) form1 to var in this
FOR-AS-EQUAL-THEN clause.
I can see FOR-AS-EQUAL-THEN as different from any other FOR-AS clauses.
Let us assume the Spec means what it says here, and the variable is
assigned to (remember there is an "=" after all!) in the first
iteration.
As you noted elsewhere in this post, the Spec uses `bind' to refer to
the initial `binding' of loop vars for [practically] all other FOR-AS
clauses.
| What is the prologue?
|
| 6.1.1.4 Expanding Loop Forms
|
| The loop prologue contains forms that are executed before iteration
| begins, such as any automatic variable initializations prescribed by
| the variable clauses, along with any initially clauses in the order
| they appear in the source.
But you missed this from the preceeding paragraph!
"Implementations can interleave the setting of initial values with the
bindings . However, the assignment of the initial values is always
calculated in the order specified by the user. A variable is thus
sometimes bound to a meaningless value of the correct type, and then
later in the prologue it is set to the true initial value by using
setq. One implication of this interleaving is that it is
implementation-dependent whether the lexical environment in which the
initial value forms (variously called the form1, form2, form3,
step-fun, vector, hash-table, and package) in any for-as-subclause,
except for-as-equals-then, are evaluated includes only the loop
variables preceding that form or includes more or all of the loop
variables; the form1 and form2 in a for-as-equals-then form includes
the lexical environment of all the loop variables."
The last two sentences are suggestive.
So FOR-AS-EQUALS differs from other for clauses in another way: It has
in its environment, ALL the other loop variables.
And, with some dull imagination we can argue that they won't have some
meaningless value of the correct type FORM1 is executed. Which would
only happen after the prologue (where all the other values are
initilized) was executed. Ensuring this would imply that evaluation of
FORM1 can happen only AFTER the prologue is executed.
After the prologue is executed, some termination tests run, then the
first iteration begins, when FORM1 is evaluated and VAR is set.
Convinced ? :)
[...]
| Now for some holes:
| - it is not specified that the variable in a FOR-AS-IN-LIST is
| initialized. Only that it's ``bound'' to the successive values of the
| list (6.1.2.1.2). Unfortunate language, yet again! The word bind is
| being misused. A variable binds a symbol to a memory location, which
| holds a value. The variable denotes that memory location, not the
| value. Stepping a loop variable means overwriting the memory location,
| not creating a new binding. Argh. If we look at FOR-AS-IN-LIST it in
| the most abstract way, FOR I IN '(A B C) means that I is intialized to
| A before the first iteration, and then is to be stepped to B, and then
| stepped C. This is how it fits into the high level model of
| initialization and stepping.
I can't sue for misuse here. The same variable is bound to successive
values of the list. Setq can be used to modify the binding. no problem.
Aside: This is a perennial source of newbie confusion for those (typically
coming from scheme and using CL:DO) who capture the variable inside the
loop body ala
(let* ((l (list 1 2 3))
(f (loop for x in l collect (lambda () x))))
(mapcar 'funcall f)) ;; => (3 3 3) not (1 2 3) from new bindings.
Also in other parts the Spec is very clear about "Binding
vs. Assignment" in the DO/DO* page, where it says
"Before the first iteration, all the init-forms are evaluated, and
each var is bound to the value of its respective init-form, if
supplied. This is a binding , not an assignment; when the loop
terminates, the old values of those variables will be restored. For
do, all of the init-forms are evaluated before any var is bound."
| - there is ambiguity regarding the relatinoship between termination
| tests and the loop body. 6.1.1.4 claims that the loop body contains
| termination tests. (I quoted that part already). But 6.1.1.6 Order of
| Execution says that termination tests are done just before the
| execution of the loop body! (Quoted that already too). So terminatino
| tests are either in the body or not. Of course, the body has to
| include everything that is repeated, so 6.1.1.4 is right. There is
| nothing but the prologue, the body and the epilogue. So 6.1.1.6 should
| say that the termination tests are done just before the remainder of
| the loop body. The termination tests /are/ the first thing to be done
| in the loop body; variable stepping is done at the end of an
| iteration, and initializations are in the prologue!
I don't see a hole here either. As you quoted, iteration-control-classes
"perform termination tests, generally just before the execution of the
loop body." but the loop body may contain other termination tests
elsewhere (from the `until' clause, say)
--
Madhu
PS I'd be surprised if this had not been debated to death previously on
CLL. I didn't try too hard to remember.
[1] The problem isn't about FOR-AS-IN-LIST at initially surmised, in
your message
<9ad1f155-bb19-4ab1-9717-209ad95a9bfd at n20g2000hsh.googlegroups.com>
This example does not have a FOR-AS-IN-LIST clause but still reads a
value of NIL for X :
* (loop for x = '(10 20 30) for y below (car x) repeat 3 collect y)
On Feb 8, 3:58 am, Madhu <·······@meer.net> wrote:
> I can see FOR-AS-EQUAL-THEN as different from any other FOR-AS clauses.
> Let us assume the Spec means what it says here, and the variable is
> assigned to (remember there is an "=" after all!) in the first
> iteration.
Regarding that "after all"; the = sign doesn't universally signify
assignment in computer science!
In some languages, it could be either initialization or assignment,
like C:
int x = 5; /* initialization */
x = 6; /* assignment */
In the syntax of some functional languages like ML et cetera = denotes
initialization. (Surely not assignment!)
How about Pascal? It uses = for manifest constants and defining types.
const foo_length = 5;
type session_id = integer;
The assignment operator is spelled := .
> variables; the form1 and form2 in a for-as-equals-then form includes
> the lexical environment of all the loop variables."
>
> The last two sentences are suggestive.
Sigh. If a for-as-equals-then has /all/ loop variables in scope, that
means it has its own loop variables in scope also. This is valid:
FOR X = X THEN X
And this means that the semantics are assignment. Something can't be
initialized from itself.
Still, it's /possible/ for every FOR clause to have all variables
(including its own) in scope, as that paragraph says. Scope means
little, since the variables can be all introduced in one big LET, and
initialization can all simulated by assignment. Elsewhere it is said
that the initializations and steps are done in the order of appearance
of the forms. That is without regard to any scoping considerations.
Initialization is abstract here; the user doesn't care about, and
should not be exposed to, the implementation detail that some (or all)
variables were actually initialized to NIL and then assigned with
their initial values.
> So FOR-AS-EQUALS differs from other for clauses in another way: It has
> in its environment, ALL the other loop variables.
>
> And, with some dull imagination we can argue that they won't have some
> meaningless value of the correct type FORM1 is executed. Which would
> only happen after the prologue (where all the other values are
> initilized) was executed. Ensuring this would imply that evaluation of
> FORM1 can happen only AFTER the prologue is executed.
>
> After the prologue is executed, some termination tests run, then the
> first iteration begins, when FORM1 is evaluated and VAR is set.
>
> Convinced ? :)
I think I'm only becoming convinced the LOOP blows, which wasn't my
intention at all with this thread, subject line notwithstanding.
Madhu wrote:
> * Kaz Kylheku Wrote on Fri, 8 Feb 2008 09:20:10 -0800 (PST):
>
> | I think I'm only becoming convinced the LOOP blows, which wasn't my
> | intention at all with this thread, subject line notwithstanding.
>
> Also with this unfortunate trollish subject line[1], I suspect this
> thread has likely been killed the CLL veterans who might have otherwise
> been able to offer some insight or condolence or something
I think at this point we get a suggestion to try the iterate package,
and it might be interesting to see if y'all have any better luck with
that or run into the same issues. I wouldn't know, I won't be learning
iterate for another eight years, if at all cuz I do not plan to be
programming in eight years.
As for:
(loop for x = '(1 2 3) for y in x collect y)
Well, all I can say is, LOOP is like a 4GL. They look great and powerful
and expressive and all that, but the minute you step outside "hello
world" the wolf inside the sheepskin starts gnawing on you. It's kinda
like list structure -- not too long into Lisp ya gots to know what is
going on down in the cars and cdrs.
How to find out? I saw a lot of excerpts from the CLHS. Stop that. Well,
some people can read that thing, but the only stuff I can follow is the
stuff on things I already understand.
Me, I almost never have a problem with loop, partly because I use it for
everything. I think one needs that level of steady use to get the
fluency. And this for-for thing can still surprise me. When in doubt I
make little toy examples like the above rubbish and figure out how loop
works by watching it. Too primitive? You may recall that I am a working
Lisper, I just have to get my code working, meaning it is unlikely you
will find me arguing with Lisp or the CLHS.
> [1] No doubt masterminded by Kenny
I think the problem is not so much the subject as it is the content,
which is just uninformed flailing.
I did get some good feedback on my original LOOP sucks thread, which was
that (apparently) some other editor indents LOOP "and"s a little more
than fors to make the relationship apparent. I should submit that to franz.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
"Ken Tilton" <···········@optonline.net> wrote in message
······························@cv.net...
>
>>
> I think at this point we get a suggestion to try the iterate package, and
> it might be interesting to see if y'all have any better luck with that or
> run into the same issues. I wouldn't know, I won't be learning iterate for
> another eight years, if at all cuz I do not plan to be programming in
> eight years.
>
The best programming is subliminal
mk5000
"It became more of a job than a sport to play".William Gates: "Hoop Dreams"