World: r4wp

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)

Easy enough to add sigils to make it special. I don't general go 
as far as a gensym approach for things like this.

Yes. Too early for my brain here, but 'is known-word honored in the 
bind? e.g. "set with reduce (args)"

That is, 'with is special no matter what known-word you use, correct?

Marc, your "private variables" like 'with, _recur_ can be made more 
private not needing to use the PROtECT function, in fact.

Ah, no, I think I get it now.

I don't think you need 'with  at all, you can throw back the new 
parameters as an argument of the throw function, like:
>> throw/name reduce args 'recurse

also, there is a problem with the result I think

(I mean the function result)

steeve: ooh, good point

ladislav: ah yes, there is

Here is a version with no locals, no temporary context, no shit and 
not tested ;-)

rfunc: func [spec body][
	func spec compose/deep [
		forever [
		   set [(spec)] catch/name [
			  return (func spec body) (spec)
		   ] 'recur
		]
	]
]
recur: func [args][throw/name reduce args 'recur]

wow

works well - full thing here: http://0branch.com/highlight/snippets/rfunc4.r

to return a value and stop the function you need to use 'return instead 
of 'break

I think

recur (Must be in tail position)
 -> not needed anymore

well, it has to be a tail call

it's a tail call but it can be anywhere in the function body

so you couldn't do   x + recur [ y ]

sounds like we mean different things by 'tail position'

it seems

Yep, it seems

Yep, it seems

i mean this: http://en.wikipedia.org/wiki/Tail_call

(lag)

It's tail call recursion yes, but tail position usualy means "physically 
placed" at the tail (in our context, at the end of the body of the 
function)
Anyway...

not be pedantic, but i linked to that for the opening two sentences:


In computer science, a tail call is a subroutine call that happens 
inside another procedure as its final action; it may produce a return 
value which is then immediately returned by the calling procedure. 
The call site is then said to be in tail position, i.e. at the end 
of the calling procedure.

Okay T_T

i've never heard tail position refer to last 'physical place'

anyway, not important

I just decided it would be a new paradigm :-)

heh, good stuff

thanks again for the help

No prob I was lazy on my couch

Marc, to no pollute this group I posted a private conversation mentioning 
how to define a TAIL-CALL function using the function spec and how 
to handle the situation even if the function spec is "more complicated" 
than just a block of words.

It's Rebol School group here. Why would your post be a pollution 
? I don't get it

It is a bit long to my taste, but I can repost here if you prefer. 
Also, BTW, welcome to REBOL, Marc

Yes wellcome Marc. (Not really a beginner though)

Yes Ladislav I've nothing against a long post here since it's related 
to the topic, or if you prefer you can use a copy/past service in 
the cloud.

thanks guys

OK, this is the long version:

tail-func: func [
    {

  Define a recursive user function with the supplied SPEC and BODY.
     	The function can use a special TAIL-CALL local function
     	to perform a tail-recursive function call.
    }
    [catch]


 spec [block!] {Help string (opt) followed by arg words (and opt type 
 and string)}
    body [block!] {The body block of the function}
    /local the-function tail-call context-word
] [
	; define a new 'tail-call local variable
	tail-call: use [tail-call] ['tail-call]
	
	; bind the given BODY to "know" the 'tail-call variable
	body: bind/copy body tail-call
	
	; find a local word in SPEC
	context-word: find spec word!
	if context-word [context-word: first context-word]
	
	; define the TAIL-CALL function
	set tail-call func spec compose [
		(
			either context-word [
				; set parameters to the new arguments
				compose [set parameters values? (context-word)]
			] [[]]
		)
		throw/name none 'tail-call
	]
	
	; define the function
	the-function: throw-on-error [
		func spec compose/deep [
			(either context-word [context-word] [[]])
			while [true] [
				catch/name [
					return do [(body)]
				] 'tail-call
			]
		]
	]
	
	if context-word [
		; get the function context
		context-word: bind? first second :the-function
		
		; replace the context word in the function body by NONE
		change second :the-function none

		; adjust the TAIL-CALL body
		; replace the 'parameters word

  change/only at second get tail-call 2 bind first context-word context-word
	]

    :the-function
]

values?: func ['word] [second bind? word]

Hum Ok, I see the 
>> return do [(body)]
as a nice optimization of my code.
But for the rest, I'm not sure...

example:

            safe: tail-func [x] [
                if x > 20000 [print x exit]
                tail-call x + 1
            ]