It's in the "Iteration, composition" library:
It's probably useful (and I'm generally a fan of LET) ... but the HELP-text I find somewhat enigmatic, as it refers to a COPY block in Variables, which I haven't been able to find yet. The manual isn't particularly helpful either (ref. man 8.0, p. 26).
Can anyone give examples of its application?
After looking at the code for a little while, think I've figured it out, maybe - this script says the numbers from 0 to 10.
It seems really useful for callbacks and stuff.
EDIT: So I haven't used this library very much before, but it turns out that a lot of the problems I had with my programs that I had no idea how to solve are able to be solved by this library... the more you know, I guess
Yeah, it's Lisp's answer to iteration features (FOR, WHILE, etc.) in other languages.
But yeah, the documentation needs work. On my list.
I developed it a little further, in order to make it easier to understand and use. My implementation is recursive as well. Everything except the actual actions to be performed during each iteration is integrated into the control block, just like in e.g. a FOR-loop.
Here's what "just add code" looks like (I used @pajamaclaws21 's example, see post #2):
What do you think ... library material?
That is a FOR loop! It's just C-style instead of Lisp-style. Although, in order to make the upvar mechanism work, you have to have the loop variable and its initial value separated; real C-style would have SET # TO 0 instead of the "from" input. And of course you have the BY and WHILE inputs in the other order from C.
(By the way, I was surprised that you used the empty input feature rather than dragging the # upvar into (# + 1) and (# ≤ 10). That'd make it look even more C-style. Alternatively, you could have had an empty input in the SAY block.)
So: Library? Maybe, but we should discuss those design decisions. (Worth noting in that context that everyone else ganged up on me recently to drag me kicking and screaming into disallowing substitution into an empty input slot in FOR EACH ITEM; you have to use the upvar.)
I remember that time. I think I was actually a part of it.
In a forum dedicated to a language mostly based on what's often called a Lisp dialiect that sounds like a mortal sin :
However, I based my control block on the Snap! Iteration library's 
, which you (@bh) in post #3 called:
As I mentioned in post #4, all I changed was including the entire control variable handling into the control block itself. So I don't understand why it would be "C-style" (to be honest I never wrote a line of code in C, I don't consider that an interesting language, and so hard to read; so I'm not even sure what C-style is - I'll assume you're hinting at the imperative programming paradigm).
Here's what an imperative style implementation of my ITERATE-block (I chose that provisional name because it has not been used yet for a Snap! primitive or in a library) would look like:
.
But you do have a point in that it's a generalized FOR-block. Even more generalized than the Iteration library's 
(but my implementation is less imperative-stylish!)
Now in theory is even more generalized, because the the loop / stop condition could be something other than a function of the upvar, like in:
However, this kind of iteration is quite exotic, and I guess in 99% of the cases the upvar (a) will exclusively be used as a control variable, like in an FOR-loop. And in those cases my ITERATE-block is more understandable and user-friendly (IMO). So I think it would make a nice addition to the Iteration library.
I agree with the "gang". Even when the possibility exists, it should not be used. Using it is bad for code readability, moreover its result depends on the implementation of the control block, which is even worse, e.g.: it works with the recursive implementation of ITERATE but not with its non-recursive implementation. Implementation details should not be relevant for its use, isn't that a Golden Rule of Good Functional Programming Practice (or even with any programming paradigm)? Talking about mortal sins ... 
The irony of this is that a non-recursive (more "C-stylish"?) implementation of loop-constructs prevents a bad user practice.
The C-style FOR notation is important even if you don't program in C because you probably do program in one of its children (Java, JavaScript, Python, etc.) and they use the same notation:
for (i=1; i<11; i++) {do stuff}
and what it does is start with the initialization (i=1) which can be any instructions, initializing multiple variables for example, then it computes the end test (i<11), which can be any predicate, but it's not really an end test but rather a not-end test because True means to continue the loop, then if the test comes out True it runs the body of the loop, then it does the iteration command (i++) then back to the end test. Note that this does FROM I = 1 TO 10, not TO 11, because 10 is the last value for which the end test is True.
Say what? It doesn't depend on recursion; it depends on giving RUN the iteration variable as an argument for the commands it runs. So I just changed RUN ACTION WITH INPUTS I to just RUN ACTION. Kicking and screaming.
Ooh this pushes a button for me. We are not in the business of preventing users from doing anything! Otherwise we'd be a purely functional language. We want to expand the ways users can think about their programs, so we give them iteration and recursion and HOFs and APL hyperblocks and object oriented programming. And someday we'll add logic programming. And users can create their own tools if ours aren't good enough for them. To this day, when we want to show off Snap! in a single picture, it's
➞
(How do I get the pictures to be vertically centered?)
I forgot to say: No sins here! All I meant is that your FROM, BY, and WHILE are like the three things in the parentheses after the word FOR in C and its children.
As a matter of fact, in college I used mostly Niklaus Wirth languages (no children, but more like well-bred cousins of C). As of late, trying to get my son interested in programming, I became interested in block languages, mostly Snap! now - you may take this as a compliment 
What I meant was: 
, without the iteration variable, wouldn't work with a recursive loop. But as I see now, I was 
ing up the wrong 
. Only 
needs the iteration variable as input. Sorry for the mix-up on my side!
I was at least half-joking, of course. I guess you knew.
Thanks!
Python actually doesn't use that notation, in fact, here's a python for loop.
for i in range(0,10):
pass
Python for loops are always iterating over something, a range, list, dictionary, or an iterator, not necessarily increasing a variable. (If you change the variable mid-loop, it goes to the value it should be, instead of going on with that new value).
Now of course you can actually create a c for loop in python, it would just be a while loop like this
i = 1
while i < 11:
i += 1 # I don't know if i++ works
pass
it doesnt
Oops, sorry!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.