World: r4wp

Doc, it was for Try Rebol site, not my own one attempts to test ...

REPEAT is instant here in the console I just compiled.

Joined Trello. Joined Reddit. I must care. :-)

Petr, you're looking at network delay

Close to 5000 hits on red-lang.org now.

Even if Red is not yet ready for prime time, it is good to have some 
devs having at least heard about it. When we'll launch Red for real, 
that will greatly help it spread around.

Indeed. That's great Doc.

New SYSTEM function added (meant to mimick the SYSTEM object until 
we have object support).

red>> system/version
== "0.3.2, 25-Mar-2013/2:03:45+1:00"
red>> system/platform
== Windows
red>> length? system/words
== 290

So now, who wants to implement WHAT function? ;-)

BTW, we need to add doc-strings to all functions in %boot.red, I 
like the Rebol short but meaningful strings, but I have a few questions 
first:

1) Could we borrow them from R3?

2) Does that fall under Apache license too (I guess so, but just 
checking)?
3) In such case, where and how do we to put proper credits?

BTW, now SYSTEM/PLATFORM replaces previous PLATFORM? function.

R3 doc strings were released as part of the source, so they are under 
Apache. They would taint Red to fall under the Apache licence, too, 
making it more restricted than BSL and incompatible with GPL

Doc: is it intentional?
red>> repeat i 10 [  ]
== 10
red>> i
== 10

AFAIK it is and I really don't like it.

Can this decision be explained, please?

It is intentional and has several purposes: 


a) avoiding the creation of an hidden context for each iterator instance 
and especially the costly deep BINDing of argument block on each 
call.


b) making the iterator word available outside of the loop, can be 
useful when early breaking from loop, avoiding the passing of the 
counter through a BREAK/RETURN. It can also be used to check if the 
loop counter has reached its limit or not.


c) it is IMHO counter-intuitive for users, after a few years you 
get used to it, but it is a wall that every new user will hit more 
than once. I think that the extra step of defining it as local word 
is really not a big deal in comparison. Also, FUNCTION constructor 
could be enhanced to take care of that for you.

I think that my trade-off for Red is "better", but we can discuss 
it if I have missed something.

How the outer REPEAT remembers the value i?
red>> repeat i 3 [print i repeat i 2 [print [tab i]]]
1
        1
        2
2
        1
        2
3
        1
        2

And the last value is 2, not 3.
red>> i
== 2

It is a bit confusing.

Even the outer REPEAT doesn't return its last value in this case:
red>> i: repeat i 3 [print i repeat i 2 [print [tab i]] i]
red>> i
== 2

But normally it does:
red>> i: repeat a 5 [4]
== 4

I don't want iterator word available outside of loop, this is really 
bad idea.

I *feel* same way, I usually use i, j, k, t, s as /local words to 
functions, and I don't worry to mess them with iterator words inside 
function. But we should explain why or how it is a bad idea to Doc 
(if it really is)

What does this do (I don't have access to Red here):

repeat i i: 3 [print i]

red>> repeat i i: 3 [print i]
1
2
3
red>> i
== 3

hmm... yes, I guess that makes sense.

but importantly, not necessariy for the same reason as in REBOL.

I guess we need consistency. Do any other loop functions in Red behave 
this way?

All behave the same way.

Bad idea

 is not an argument. You should look at it with a fresh view, if we 
 got used to it after several years, it doesn't mean that it was a 
 good design choice in the first place.

How the outer REPEAT remembers the value i?
 Iterator word value is stored on stack, recursively.

Doc: What do you think about the examples above? About return value.

Anyway, you shouldn't use the same word for nested loops, that is 
just confusing and will lead to errors.

But if there is no extra binding, how does this work as expected?
red>> repeat i 3 [print i repeat i 2 [print [tab i]]]

Return value: it looks logical to me, REPEAT returns the last value 
from body block. In your example, the last value in the last iteration 
is 2 (because `i` is set to 2 by the inner REPEAT). Same rule as 
for your second code example.

how does this work as expected?

 I just answered that above: "Iterator word value is stored on stack, 
 recursively."

I see. What about FOREACH, it looks it behaves different:
red>> foreach i [1 2 3] [ ]
red>> i
== none

That looks like a bug to me.

You should all think about the cost of a), such cost is paid in geometrical 
proportion in case of nested loops. Loops are at the heart of a language 
performances. Implementing it the R2-way (not sure how R3 handles 
it) would kill Red performances.

If it's a stack, then there would be a small difference in letting 
the word pop, at the end of the loop, which makes it not available 
outside the loop, versus not popping it, leaving it available outside 
the loop, would there not?

It's the word's value that is stored on the stack by REPEAT (or other 
iterators), not the word itself. Words are part of contexts, that 
may or may be not stored on stack. Anyway, you can't add or remove 
a word from a local context in compiled code, at run-time.

You need to created a new context on each REPEAT call (or use some 
hacked way of caching it) and you need to BIND the loop body (even 
probably BIND/COPY it to be cleaner). Now think about the costs of 
nested loops...and all that because you don't want to define another 
local word, that could anyway be added for you by FUNCTION. Think 
twice about the trade-offs.

I submitted the FOREACH issue on github.

Thanks.

I find that the way Rebol handles it is more a limitation than an 
help. When checking for local words, you need to keep in mind two 
lists: one for the local words to collect, one for the iteration 
words, to leave apart. I prefer one simple rule rather than two rules. 
Making a few more keystrokes to add those iteration words to /local 
list is easier for me, than wasting brain processing power to tell 
apart which words I should collect, which one I should not.


Moreover, if I want the iteration words to be defined in the function 
or global context, I can't in Rebol...Looks definitely more like 
a limitation than an help to me.

Huh, it seems that both current versions of R2 and R3 are not binding 
the loop body on each call to the hidden context:


>> foo: func [code [block!] /local a b][a: 1 b: 2 repeat i 10 code]
>> foo [a: a + b]
** Script Error: a has no value
** Where: foo
** Near: a: a + b


I'm pretty sure I've seen it, maybe in older versions. Anyway, if 
current Rebol versions are not making that binding on each call, 
it makes most of my point a) irrelevant. So, you can forget about 
the binding cost. :-) Still the other concerns and limitation remain.

Hmm, my code is not testing the right binding...

>> foo: func [code [block!]][repeat i 1000 code]
>> foo [i]
== 1000

So both R2/R3 do re-bind the body block on each call.

Red would raise an error ("word has no value!") running the same 
code in the interpreter. You would need to write it this way to make 
it work:


    foo: func [code [block!] /local i][repeat i 1000 bind code 'i]


That makes the required BIND operation explicit, so the same flexibility 
as in Rebol could be achieved but in a user-controlled way and only 
when needed.

foo: func [code [block!]][repeat i 1000 code]
foo [i]


Doesn't raise an error in Red console for me. It works fine. Delcaring 
the word local to FOO does cause the error for each pass.

My first reaction was the same as Endo and Bolek, because I'm used 
to the way it is. I rarely have to alias a loop counter for access 
outside the loop, and I like the language being smart enough to help 
me, so I don't have to declare these things all the time, or worry 
about leakage.  However, my recent work on the idea of a new, general 
LOOP func (%mezz/new-loop.r here for those who didn't follow it) 
made me keenly aware of loop costs.


I've only had a few instances where it really mattered, but I've 
still almost always avoided FOR, for performance reasons.  Doc thinks 
things through carefully, and he has already said that FUNCTION could 
probably be smart enough to handle things for us, but we would have 
to consider how that works, to avoid environment dependent behavior. 
And how it affects very simple map/filter funcs. That is, do those 
one-liners now need /local specs.

Now is the time to discuss this, but it sounds like Doc has thought 
this through, and made his choice for clear reasons. If he's set 
on it, then we should look at what, if anything, needs to be done, 
to make Bolek, Endo, and others happy.