On 10/30/2017 10:27 AM, Rhodri James wrote:
On 29/10/17 16:45, Alberto Riva wrote:
On 10/29/2017 11:13 AM, bartc wrote:
(What the OP wants was also proposed a few weeks back in comp.lang.c.
But that was only within nested functions, so if H is inside G, and G
is inside F, then a 'returnall' from H would return directly directly
from F. Apparently Lisp allows this...)
Well, not directly, but it can be simulated with the condition system
(equivalent to try/except) or with throw/catch, which is similar but
doesn't use exceptions.
But my point was that in Lisp you don't need to do this, because you
can write a macro that expands into a return *in place*, without
calling a separate function, and this eliminates the problem entirely.
Since Python doesn't have macros I was looking for the next-best
solution, but there doesn't seem to be one. Oh, well...
You can do the same in C. I've had the displeasure of trying to
maintain such code. It was near-unreadable, because it constantly broke
your expectations of what the code flow *could* be. The fact that
something that could return from the middle of your function without the
slightest indication was a rich source of bugs.
Just curious: how is this different from calling a function that throws
an exception (that may or may not be caught by some other function
higher up in the call stack)? That also breaks your expectations of what
the code flow would be...
To clarify, I agree with your concern. What I mean is that even in
normal conditions there's never any guarantee that the code flow is what
you expect it to be just by reading the body of a function. The kind of
statement I was trying to add would at least have made that explicit:
return-if-so-and-so-happens.
Alberto
--
E-mail address:
((lambda (s a b c) (map 'string #'code-char (mapcar (lambda (v)
(setq s (+ a (mod (+ s v (- a)) b)))) (map 'list (lambda (v)
(- (char-code v) c)) " 1`-THUZ&+Wh1")))) 97 46 73 32)
--
https://mail.python.org/mailman/listinfo/python-list
