World: r3wp

You don't notice this in R2 because they're mezzanine and all of 
that overhead is greater, but it is noticable in R3 where they are 
native.

Wouldn't it be more efficient to just BIND instead of BIND/copy body 
blocks in loops by default, and additionnally provide a /copy refinement 
in the (very) rare cases where you don't want the body block to be 
modified? Is it a design decision or did I missed some obvious reason?

You have to BIND/copy or *EACH would not be recursion-safe (or task-safe 
in R3).

I thought about the upcoming task! support but forgot about the "recursion" 
case. I might have wrote only 3 or 4 functions in 10 years of coding 
in REBOL that fall in that case (that's why in R2, it could have 
been no-copy by default). But tasking in R3 should make it more frequent 
I guess.

I guess I write more recursive code than you do :)

That's very possible, I use recursion only when the gain in code 
size or clarity looks obvious. Also, not having tail-call optimization 
doesn't push you much toward recursive approach in the general case.

I use it for building or processing recursive data structures - it's 
faster for that, tail-call-optimized or not. I only switch to iteration 
and hacks if the data blows the stack, which is rare.

The recursive calls limit used to be quite low (150-200 calls), has 
that limit been extended in recent 2.7.x versions?

I think so, but don't know. Haven't run into it so far, since I don't 
do recursive loops, just trees.

So you don't use recursive calls inside FOREACH loops...

Too restrictive.

I agree, using recursion for walking through hierarchical structures 
is a good approach as these structures usually have a depth limit 
far below the stack limit (e.g. parsing XML data) . In the last years, 
I've found that using block parsing for block! trees walking was 
probably the most efficient approach (code size and speed wise).

yep i use parse too, to do so. It doesn't need rerursives functions

faster, One call with parse

I prefer to use PARSE when I can, but recursion can be tricky if 
you use local variables. Not (always) impossible, but tricky. It's 
on the list to be fixed with the R3 parse proposals.

I know, i saw many implementations wich use recursive calls of parse 
(to deal with local var) in the past.
But i don't like that.

I saw it's slower most of the time than using recursive rules (well, 
it's the purpose of parse)

It's not always possible to refactor the parse rules to make the 
variable usage recursion-safe. Most of the time it is though.

even in that case, i prefer to code an emulated stack (using a block)

That can be slower than recursive calls to parse, depending, but 
at least you won't blow *that* stack.

There is another one advantage of using your own stack, you can break 
the process where you want and continue it later.
Used to do incremental parsing (even with recursives rules).

I also use block! stacks to avoid local words issues in recursive 
parse rules. It would be interesting to benchmark the two approaches 
: (recursive functions) vs (recursive parse rules+custom stack).

Here's an example: Come up with a recursive-parse-rule version of 
the ARRAY function, including the function value calls. Compare.

Wait, bad example. ARRAY is generative, so it is likely a bad candidate 
for PARSE.

afaik the rebol stack goes a few thousand funcs before failing... 
 but that depends on the amount of params you have on the functions, 
more args = more stack use.

rebol stack limit: 

>> i: 0 a: func [][i: i + 1 a] a
** Internal Error: Stack overflow
** Where: a
** Near: i: i + 1 a
>> i
== 14265

REBOL/Core 2.5.0.3.1
>>  i: 0 a: func [][i: i + 1 a] a
** Internal Error: Stack overflow
** Near: a
>> i
== 3151

Rebol/View 2.7.6, 64-bit Ubuntu Hardy
>>  i: 0 a: func [][i: i + 1 a] a                      
** Internal Error: Stack overflow
** Where: a
** Near: i: i + 1 a
>> i
== 1705

1704 on /Core 2.7.6 on the same system

wow this is pretty weird.

I tested  with rebview on windowsXP

REBOL/Core 2.7.6.4.2 on 32-bit Ubuntu 7.10
>> i
== 1705

REBOL/Core 2.7.5.2.4 on MacOSX Leopard:
>> i
== 1334

So WindowsXP is more recursion-friendly than Leopard...finally a 
good argument to not switch to MacOSX! ;-)

REBOL/Core 2.5.8.3.1
>> i
== 3150
REBOL/View 2.7.6.3.1
>> i
== 14265

Both on WinXP.

1334 parameterless functions... that's not nearly enough for many 
algorythms!  :-(  this really has to be addressed in R3.

its strange that view on XP has TEN times the amount of lowest target.

because of the compiler option /Strange in GCC i guess

but why did that get set differently on winxp... maybe its something 
that carl never really officially set as part of the distribution 
specifics.

Because Carl is not using GCC for Win builds?

Here's something stranger

>> i: 0 a: func [z][i: i + 1 a 1] a 1                    == 1704
>> i: 0 a: func [z y][i: i + 1 a 1 2] a 1 2            == 1706
>> i: 0 a: func [z y x][i: i + 1 a 1 2 3] a 1 2 3    == 1705

One stack for calls, one other for parameters perhaps

all is possible

possibly the stack includes a single payload block for calls... this 
would make sense, in preventing stack depth variance.

meaning parameters are not stored in the call stack :)

Carl would not be using GCC for Win builds, because REBOL is older 
than the short time period that GCC has been good on Windows

It would also depend on platform-specific stack handling.

possibly, yes, by indirection.  push stack [func args-block]

and args-block is a mem copy of the args block with local values

this is all speculation though... hehehe

what I am surprised overall is that rebol does not simply increase 
stack space.  isn't that possible in current OSes?