I do not believe that there is anything meaningful about FB@:FT relevant to tail recursion.
A tail recursive function has the characteristic that no matter how deep you nest the stack, the result returned from the final result will be the result of all routines which called it. This matches how inductive verbs work. The difference, of course, is that there is no stack (which is all that tail recursion was about in the first place). The requirement imposed by induction is that you refactor the original recursive function so that the test (for whether you enter recursion) be separable in some way from the rest of the code. How does FB@:FT have anything to do with any of this? Thanks, -- Raul On Tue, Jan 9, 2018 at 6:51 PM, Jose Mario Quintana <[email protected]> wrote: > I am not entirely sure what you are trying to convey either. Apparently, > you are implying that "F=: FB^:FT^:_" would be, in some sense, simpler than > the original F but that might not be necessarily the case (depending on the > nature of FB and FT; which you did not specify). > > Your claim, to me (so far), is not much different than, for example, > > If I have a recursive verb (F y) implemented in J, which satisfies the > constraints for tail recursion, I believe that there is always a pair > of companion functions (FB y) (FT y) such that an F workalike can be > written: > > F=: FB@:FT y > > (So what?) > > > On Mon, Jan 8, 2018 at 7:45 PM, Raul Miller <[email protected]> wrote: > >> I'm not entirely sure what issue you are trying to raise here, so I will >> guess: >> >> In languages which support tail recursive optimizations for recursive >> functions, those optimizations can still be deployed if the function >> in question contains an expression which uses some different recursive >> function. Why should J's induction be any different? >> >> Thanks, >> >> -- >> Raul >> >> >> >> On Mon, Jan 8, 2018 at 7:08 PM, Jose Mario Quintana >> <[email protected]> wrote: >> > The claim [2], as written, does not impose any restrictions on FN or FT >> > apart from being monadic; thus, F itself could be embedded in FB and >> could >> > provide an opportunity to cheat and defeat its purpose. >> > >> > Surely you mean something more substantial. Can you elaborate your >> claim? >> > >> > >> > On Wed, Jan 3, 2018 at 8:09 AM, Raul Miller <[email protected]> >> wrote: >> > >> >> [1] >> >> >> >> If I have a tail recursive function F, which calls function G, there >> >> is normally no problem with G signaling that F needs to exit. Just >> >> return a distinguished value from G and in F have an if statement >> >> which returns when that happens. Since F is tail recursive, nothing >> >> more needs done. >> >> >> >> So I would like to see an example of how this description: >> >> >> >> >> I have a deeply embedded function that discovers that it has >> completed >> >> the >> >> >> task set before it. ... >> >> >> >> >> >> This function was not part of the initial design. >> >> >> >> has anything to do with tail recursion. >> >> >> >> [2] >> >> >> >> If I have a recursive verb (F y) implemented in J, which satisfies the >> >> constraints for tail recursion, I believe that there is always a pair >> >> of companion functions (FB y) (FT y) such that an F workalike can be >> >> written: >> >> >> >> F=: FB^:FT^:_ y >> >> >> >> which satisfies the "bounded stack usage" guarantee of tail recursion. >> >> And this form has an additional advantage, which is that a rewrite >> >> which removes the bounded stack character requires work on the part of >> >> the developer which is quite significant - it's unlikely that you will >> >> have someone making such changes without realizing that they are doing >> >> so. >> >> >> >> But I would be interested in seeing a counter-example that destroys my >> >> belief, if counter examples exist. >> >> >> >> Thanks, >> >> >> >> -- >> >> Raul >> >> >> >> >> >> On Wed, Jan 3, 2018 at 5:44 AM, Erling Hellenäs >> >> <[email protected]> wrote: >> >> > Try to remove all references to persons from your postings. >> >> > >> >> > I don't think my post is in any way strange. According to my >> judgement no >> >> > further explanation is needed. >> >> > >> >> > /Erling >> >> > >> >> > >> >> > Den 2018-01-02 kl. 13:18, skrev Raul Miller: >> >> >> >> >> >> If you would answer those two questions we could do that. >> >> >> >> >> >> Thanks, >> >> >> >> >> > >> >> > ------------------------------------------------------------ >> ---------- >> >> > 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 >> ---------------------------------------------------------------------- >> 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
