Re: Return

[Stephen J. Turnbull]

MON KEY writes:
 > On Tue, Dec 7, 2010 at 9:34 AM, Stephen J. Turnbull <address@hidden> wrote:
 > > MON KEY writes:
 > >
 > > No, it won't.  However, I must say (as a maintainer) that use of
 > > lambdas often imposes extra work on debuggers.  I almost always give
 > > lambdas a nickname when I'm reading code that uses them, unless
 > > they're simply implementing partial evaluation.
 > 
 > I'm sorry, but it isn't clear, for which language?

Any language that has lambdas.  Especially Ruby, where lambda (aka
anonymous block) abuse is reaching levels that demand protective
legislation for the poor little critters.

 > The question is (apropos the above) when will what happen where?
 > ;-)

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.

 > AFAIK the discussion is still re return/return-from/block and presumably by
 > proxy go/tagbody etc. with the ostensible lexbind sprinkled on top.

You're confused, then.  Sorry, I guess I should have changed the
subject to "defun vs. lambda". :-)  Of the concepts you belatedly
reintroduce here, only "lexbind" has been mentioned in the last 4 or 5
messages in this subthread, and the paragraph above applies perfectly
well to all that other stuff anyway.

 > I am curious to learn how you understand all of what you say re lexcial 
 > scoping
 > to jibe with lambda, closures, and macroexpansion at compile time, and more
 > particularly with consideration as to why Common Lisp's 
 > `lambda-lists-keywords'
 > contains an &environment and &whole?

It should be clear: I haven't even thought about it since the
publication of CLTL1, and even then I considered it a spectator sport.

But I don't need to think about it, in the question of lambda
vs. defun.

 > > Frankly, I don't see any such general acknowledgement in the general
 > > Emacs community.
 > 
 > Most likely those who might otherwise caucus more vocally have left
 > with a whimper.

I predict that's what you will do, too.  You're trying to score
debating points, but that cuts no ice here.  What counts are code and
user requirements explained in a way that makes sense to the Emacs
maintainers.  All three (code, requirement, making sense) must be
present or your feature won't make it to the distributed Emacs.