Remember that in the second example the @. conjunction is still running 
when the $: is encountered.

So what would be needed would be a flag, safe-to-tail-loop, which would 
be set by conjunctions that can promise that they will not do anything 
more after a verb is executed (and that their predecessors have made the 
same promise).  If $: is encountered with the safe-to-tail-loop flag 
set, it could replace x and y and restart the recursion in the same 
stack frame.

Still looking for an example of practical need...

Henry Rich

Raul Miller wrote:
> On Tue, Dec 22, 2009 at 6:44 PM, Dan Bron <[email protected]> wrote:
>> If I were interested in specific examples of RTCs in J (as opposed to
>> supporting TCO as general, special code) I might think of tree applications,
>> where trees are represented by nested boxes.  Of course, trees can be
>> adequately represented by (sparse) open arrays and handled as such, but at
>> least my first instinct in processing trees is boxes and  $:  .  I would
>> call that the "natural approach", and it is the sort of thing I would like
>> to see optimized (so that I don't have to come up with insightful new
>> approaches).
>>
>> I might also search the Forum archives for instances of the phrase "stack
>> error", or  $:  more generally (which won't be too overwhelming, as  $:
>> doesn't see much use in J, for the reasons previously discussed).
> 
> My problem is not finding recursive code.
> 
> My problem is finding tail recursive code.
> 
> So, ok, let's just work with factorial.
> 
> This is a recursive implementation of factorial which is not
> tail recursive:
>    1:`(* $:@<:)@.* 3
> 
> This is a recursive implementation of factorial which is
> tail recursive:
>    1 ([`(* $: <:@])@.(*...@])) 3
> 
> (Note, by the way, that the $: mechanism means that
> I can not incorporate the required left argument (1)
> into the definition of this verb.)
> 
> Anyways, with just these two verbs as examples,
> the task of recognizing (and automatically
> rewriting) tail recursive verbs seems potentially
> challenging.
> 
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to