Re: Return

[Stephen J. Turnbull]

MON KEY writes:

 > > Once you have the answer for lambda, you have the answer for defun,
 > > and vice versa, modulo the symbol deref required for a defun'ed
 > > symbol.  The answer for lambda (resp. defun) is left as an exercise
 > > for the reader.
 > >
 > 
 > Is such an exercise so trivial a thing?

No, it's nontrivial.  But it's not the question I was answering; the
question I was answering was the trivial one.  As Spivak points out,
answering trivial questions is the ultimate in mathematical elegance.

 > > Sorry, I guess I should have changed the subject to "defun vs. lambda". :-)
 > 
 > No, that would not have been useful for readers navigating the
 > Internet time machine.

Of course it would be useful.  Those who are interested in what you
always wanted to know about Lisp but were afraid to ask would have
known to avoid this subthread.  Me too, for that matter. :-)

 > > Of the concepts you belatedly reintroduce here, only "lexbind" has
 > 
 > It strikes me that the concept of "belated reintroduction" is exactly
 > what is under consideration here. :)

Cute!

 > Can I assume then that the nature of my query re &environment and
 > &whole wasn't entirely lost on you?

Yes.  That will be the first valid assumption you've made about what I
know or am thinking in this conversation, most likely. :-)

 > What happens where in the `lexbind' will most definitely have
 > consequences w/re unwind-protect and I would suggest an eventual (an
 > inevitable plea for) attempts to integrate some form of
 > return/return-from/block/tagbody/go/ etc.

Sure, but you complained about lack of lambda in a language (Python)
which has had to deal with all those issues, too, and has done so
fairly successfully.  If you wanted to discuss something else, you
should have made your point in different words.  The discussion about
lambda among developers of Python is *entirely* about the ugliness
and/or inconvenience of having to choose a name for a function used
only once.  Not about missing functionality.  You seem to have a
misconception about that, which I wanted to correct.

I would imagine that Lisp researchers were the first to come to grips
with these issues in many cases, and perhaps in the most generality.
But it is *not* specious to draw analogies to Python in the context of
*Emacs* Lisp.  Both languages are pragmatically designed, Emacs Lisp
as a substrate for implementing powerful editor/operating systems, and
Python as a powerful generic scripting language.  While Python does
provide solutions for all these problems, it does so in a very
pragmatic way.  Rather than try to come up with a generic syntax that
works for all functions, Python provides a (limited) variety of
syntaxes that are very efficient for situations commonly encountered
by developers using Python.  It seems reasonable to suppose that such
an approach could be useful for Emacs Lisp as well.

Of course that's debatable.  But I at least find it as plausible as
pleas for implementation of all these Common Lisp features.