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