What is a correct way to define macros `defun-rf' and `rf'
so that a creation such as

    (defun extremely-long-function-name (x)
      ...
      (return-from extremely-long-function-name 'a)
      ...
      (return-from extremely-long-function-name 'b)
      )

can be replaced by

    (defun-rf extremely-long-function-name (x)
      ...
      (rf 'a)
      ...
      (rf 'b)
      )

This doesn't handle documentation strings or declarations at the beginning
of the function body; I leave that as an exercise for the reader.

(defmacro defun-rf (func-name arglist &rest body)
  `(defun ,func-name ,arglist
     (macrolet ((rf (value) (list 'return-from ',func-name value)))
       ,@body)))

BTW, I notice you avoided using nested backquote.  That was the other
reason I did it with FLET: I don't have a Common Lisp implementation on my
machine, so I either don't test or do a little testing using Emacs Lisp,
and it doesn't do nested backquotes properly (at least in Emacs 19.34).  I
wasn't sure whether it should be `(return-from ,,func-name ,value) or
`(return-from ,',func-name ,value), and my environment didn't allow testing
it.  But then I realized that FLET could be used, so the problem was
solved.

There's one semantic difference between the two versions.  If the body of
the function contains a block that uses the same name as the function, the
macro will return from the inner block (because Lisp macros are not
hygienic) while the function will return from the outer block.  The macro
could be made to return from the outer block by having the DEFUN-RF
expansion contain its own block with a gensym'ed name and having RF return
from that instead of the function name.  But FLET solves it so much more
nicely, by using normal lexical scoping.

  I suggest you do (block nil ... (return <whatever>) ...) instead.

So all in all, _if_ he really needs this sort of stuff, I'd think that
Barry's solution (a macro introducing an flet to capture the block
label -- whether one would use nil and return or the function name and
return-from is technically equivalent here, if I'm not mistaken, but
probably the function name is more descriptive) seems best.

But I'd still be interested why he has so many RETURN-FROM forms.
Note: I'm not saying that this is evil, or that I can't imagine any
problem space that might call for so many returns.  But given that CL
has so many other ways of expressing many of the problems that returns
are used for in other languages, I'm wondering whether there's not
something more descriptive. Either an existing construct of CL, or a
more descriptive macro, which conveys his intent better.

Regs, Pierre.

To answer your nested back-quote question, I was in a hurry and
not sure either, so I did the explicit cons-thingy.
The following nested back-quote stuff works as well:

(defmacro defun-rf (func-name arglist &rest body)
  `(defun ,func-name ,arglist
     (macrolet ((rf (value) `(return-from ,',func-name ,value)))
       ,@body)))

Bernhard

(defun extremely-long-and-descriptive-function-name (...)
   (block function
     ...
     (return-from function 'a)
     ...))

This approach is almost identical to Erik's but avoids the problem of
intervening NIL blocks and is a pretty simple solution--not nearly
as sophisticated as Barry's.

As to whether needing that many return-froms is a bad sign, I don't
think so.  I actually didn't need that many, and my editor was smart
enough that I didn't actually have to retype the long function name,
just meta-click or some such incantation to copy it down.  I just
did it so that the code seemed more concise and generic.  If I changed
the name of the function, I didn't want to have to remember to change
the return-froms.  So, as long as it's in moderation, I don't see a
problem here.

Scott

--
Scott D. Anderson
Spelman College, Atlanta, Georgia
anderson @ spelman.edu
http://www.spelman.edu/~anderson/

Thank you Barry Margolin --this does just what I wanted.  It also put me wise
to `flet'.
  Thanks also to
        Bernhard Pfahringer
        Erik Naggum
        Pierre R. Mai
for other solutions/comments.           -Jonathan