(Well, i should add - when an inductive verb is representing a tail recursive function, the decision to make the recursive call is implemented in the test verb FT but the recursive call, itself, looks like a return in the body verb FB - the "returned result" there is the argument to the "recursive invocation".)
Thanks, -- Raul On Tue, Jan 9, 2018 at 8:11 PM, Raul Miller <[email protected]> wrote: > 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
