World: r4wp

re: body, is "Function body to be augmented w/ recursion context" 
not clear? [if not, will add clarification]

Actually, the SPEC block *is* modified, but in a way that may not 
matter often

It might be better, though, to not modify it at all.

what are you referring to?

the USE function modifies its argument.

are you referring to shadowed bindings?

like, rfunc [ _recur_ ] [ _recur_ ] won't do what i expect?

it would do what you expect, but:

spec: [...]
body: [....]
rfunc [spec] [body]

would cause some modifications that may be unwanted.

sorry, I meant

rfunc spec body

hmm, i haven't considered that case

However, the USE function still (in R2) does not contain any warning 
it is modifying its BODY argument...

i just thought i was setting up a new lexical scope

You are OK, most probably, but not due to the fact that USE is not 
modifying, rather due to the fact that it most frequently does not 
matter.

i'm afraid i'm not clear on what's being mutated

THat is a complicated issue, but the principle is easy. USE modifies 
it BODY and should be treated as modifying. However, you can easily 
define a non-modifying version:

    USE words copy/deep body

...and, in most cases the difference does not matter (but still, 
I prefer to be warned)

aha, thanks

i just looked at the r2 and r3 docs, i see the issue now

so: conceptually, it shouldn't matter as you're supposed to be recursing 
rfuncs with 'recur'

but semantically it would be better to address this

updated: http://0branch.com/highlight/snippets/rfunc2.r

so, if i haven't overlooked anything else: think anyone would find 
this useful?

one more style-related:

I do not know why you used the

    do [func spec wrapped]

I guess that

    func spec wrapped

should suffice.

Marcs, It only works if the word 'recur appears at the end of your 
function (like in safe).
The code flow is never interrupted anywhere else.

You should have used the throw/catch technique instead of simply 
setting a state (true/false) to control the iterations.

Besides that, I think your code is a little convoluted (basically, 
you're just inserting the body of a function in a while loop.

ladislav: oh, d'oh -- thanks

steeve: right, the call has to be in tail position; thought i'd mentioned 
that in the docs but evidently not

[a] why would thow/catch be better here?

[b] why is it convoluted to convert to a loop?

because you could use recurse from anywhere in the function not only 
at the tail

[B] it's not by definition, it's just the way you do it ;-)

hmm, okay

i don't follow your point re: recursing from anywhere (i.e., from 
non-tail position)

via the use of throw/catch

if you're not in tail position you'd still have to push stack frames

Marc's code is an implementation of tail-recursive function. Such 
implementations have been posted by some people in the past, but 
there are some minor differences between them. For example, the way 
how the arguments were passed differed from Marc's idea.

I thought you wanted to simulate tail/recursion only (it's what youre 
current code do anyway)
in that case you don't need to store the stack frame

To answer to the question: why tail recursion from anywhere ?
What if you want conditionned recursion ? 
Recurse could appear inside a IF block not at at the tail.

aha, misunderstood your point

yes, there's a shortcoming if you're recursing from within a conditional 
-- thanks for spotting that; will rework

fix: http://0branch.com/highlight/snippets/rfunc3.r

though there's still the while loop wrapping the body

The WHILE loop is necessary for what you are doing, do not worry 
about it.

damned silly mistakes -- was focused on getting the bindings etc. 
right, overlooked this prob

thanks for the help guys

The usage comment in the third version is very nice. 


On doc strings, try to keep them short, leaving detailed notes to 
the usage or other comments. e.g.

rfunc: func [

    {Defines a tail-call optimized user function, using RECUR for self-calls.}
    spec [block!] "Function spec (see: func)"
    body [block!] "Function body (modified) (see: func)"
    /local wrapped
] [
    ...
] 

Short doc strings are nicer with HELP.

thanks for the tip

Also, I try to use special names for augmentations and such. In this 
case, 'with would conflict with my WITH func.

hmm, yeah -- was wondering about that

that was originally _args_ but i switched it out so that you could 
get a more readable recur call (i.e., cheekily make use of 'with' 
so that it read better)

(for the BIND)