Erling... Have you forgotten that f^:test^:_ y is functionally equivalent to tail recursion?
But, also, why would you imagine that > 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. in any way shape or form has anything to do with tail recursion? Seriously... please? -- Raul On Tue, Jan 2, 2018 at 3:08 AM, Erling Hellenäs <[email protected]> wrote: > Hi all! > > I think you usually design a way to end the recursion. The deepest function > returns to the one above and so on. In the case of tail recursion there is > simply no stack and you would immediately return. Using exception handling > to do this does not seem proper. You'd probably want to use exception > handling for exceptions. It would also be strange and therefore it would be > hard to read and understand your code. > > As far as I know J always keeps the stack, in tacit Jx you can use tail > recursion without a stack. > > Cheers, > > Erling Hellenäs > > > > > Den 2017-12-31 kl. 01:48, skrev Nick S: >> >> Well, exit'' takes J down completely. >> >> I have read through most of the foreigns again, and through doc, and I >> searched the messages from this forum for a bit. Either I can't find the >> right search string or it has not been discussed since I have begun >> following this. I just can't find an answer. >> >> I have a deeply embedded function that discovers that it has completed the >> task set before it. (This is a continuation of my solitare game solver). >> I am doing trial solutions - and if everything works. it will declare a >> solution and end. >> >> This function was not part of the initial design. It would be >> inconvenient >> for me to return and then set a flag so that the top level solver code >> emits the right messages, although I could do that. >> >> Instead I was hoping to, from whatever level of recursion I have reached >> is >> doing trial solutions, to decide that I have met the burden of "being >> done". and simply return to the console prompt, allowing the stack to be >> thrown away. >> >> I suppose I could execute the entire thing under a try. and throw back to >> it. >> Is throw the only way to do this? I guess I could just use an uncaught >> throw, as: >> >> >> foo =: 3 : 'if. y > 64 do. y throw. else. foo >: y end. ' >> >> foo 1 >> >> $ foo 1 >> >> # foo 1 >> >> Is the answer as simple as an uncaught throw or is there a "right" way? >> >> I searched for "uncaught throw" and found >> uncaught throw. gives no message >> >> Now it does: error code 35, 'uncaught throw.' >> >> Henry Rich <http://code.jsoftware.com/wiki/User:Henry_Rich> (talk >> >> <http://code.jsoftware.com/mediawiki/index.php?title=User_talk:Henry_Rich&action=edit&redlink=1>) >> 15:06, 4 June 2017 (UTC) >> >> So that is probably something that I should not use because it will be >> fixed, I just don't have it yet. I don't want to mess with the debugger. >> I guess I could make a master catcher that runs everything but then I have >> to pass on errors or I get nothing when I have a bug. >> >> I'll admit I am being lazy. I am trying to add trial and error to a >> solver >> that works whenever there is enough info in the puzzle specification, but >> when there is not, the next trick is to try blocks in various positions, >> and when you get impossible progressions, you can eliminate a space and >> then try again. I might be descended through several layers as the >> solution is found. > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
