Thomas Costigliola wrote:
> On Tue, Dec 22, 2009 at 9:53 PM, Henry Rich <[email protected]> wrote:
>> Remember that in the second example the @. conjunction is still running
>> when the $: is encountered.
> 
> I'm not sure if I get exactly what you mean by this but as it stands
> now @. with verb right argument will execute exactly one gerund. So
> after the right verb is executed the result of the derived verb should
> always be the result of just one gerund; no others will be executed.

You're right, but my point is that it is up to each modifier to notice 
this.  If the @. had a noun right argument, I don't know where it would 
be decided that tail-recursion was OK.  If the conjunction were ^:, it 
would allow tail-recursion only if the right-hand side had evaluated to 
the scalar 1.

Henry Rich
> 
>> 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...
> 
> I doubt it will ever be an urgent necessity in J, which speaks to a
> lot of J's strengths, but it at least would give us some more options
> in solving problems.
>> 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
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> 
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to