From: Vassil Nikolov
Subject: Re: returning from a function (Ex: Re: some small  proposed  changes to standard)
Date: 
Message-ID: <l03130304b3c3e539ee9a@195.138.129.101>
(Resending, seems this didn't make it the first time.)

Kent M Pitman wrote:                [1999-07-24 02:52 +0000]

  > Vassil Nikolov <········@poboxes.com> writes:
  [proposing FRETURN to return from a function body, in response
  to a proposal to allow for (RETURN-FROM DEFUN [result]) as a
  substitute for (RETURN-FROM function-name [result])]
  > 
  > I'm pretty ambivalent about the conceptual goodness of this device.
  > A common reason to want it is that if you rename the function, you
  > have to rename the RETURN-FROM.  Some people might find that painful,
  > but it's a protection against taking:
  > 
  >  (defun foo (x) 
  >    (+ (if (zerop x) (return-from foo 7) x) 3))
  > 
  >  (defun bar (z
  >    (+ (foo z) 2))
  > 
  > and then (by sloppy editing) grabbing the body and dropping it into
  > 
  >  (defun bar (z)
  >    (+ ((lambda (x) (+ (if (zerop x) (return-from foo 7) x) 3)) z)
  >       2))
  > 
  > and just compiling it with no errors.  This will flag a reminder that
  > you've moved to a new context and you need to identify the FOO boundary.
  > If you'd instead used the FRETURN idiom, you'd find 7, not 9, being
  > returned from BAR when z is 0 once you substituted things, and you'd
  > get no compilation warning about the fact that this was going to happen.

Definitely.  But (RETURN-FROM DEFUN 7) would also suffer from the same.
My point (which I should have made more explicit) was that I'd rather have
FRETURN than returning from a block named DEFUN, leaving aside the (more
important) issue if such a thing is really a good idea to have.

By the way, I believe that FRETURN has another advantage over
(RETURN-FROM DEFUN [result]) in that the very same construct
works for DEFMACRO and for local definitions (in FLET etc.),^1
while with the other approach we would need to introduce
another reserved block name to have (RETURN-FROM DEFMACRO ...),
not to mention that it's not clear how this approach would look like
for local definitions.
__________
^1 if anyone happens to be interested in an extended version of
  what I posted, supporting those, please send me e-mail

  > In fairness, RETURN (vs RETURN-FROM) has this same problem.  It's very

Of course; FRETURN is for DEFUN what RETURN is for DO.

And, just like RETURN, it is more obvious with FRETURN than with
(RETURN-FROM DEFUN ...) that there are no promises of warnings
if the context changes.

  > easy to substitute something that has a (RETURN ...) into a new context
  > that has an extra NIL block "helpfully" inserted and not get any warning
  > about the fact that it's a different NIL block.   So it's not like the
  > language totally avoids things that cause problems of the kind I'm citing;
  > I just think it's well to learn from these problems and ask hard questions
  > about whether you want to institutionalize more of them...

In fact, it's not for me to answer since I tend not to use RETURN-FROM
with the function name to return a value from a function (if it gets
so deeply nested that one would become necessary, I'd prefer to split
it into several smaller definitions and/or rethink the design).
Therefore I have not really encountered any problems with
(RETURN-FROM function-name ...); I just saw a way whereby a specific
proposal could be improved (IMO).


Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
  Abaci lignei --- programmatici ferrei.