Re: Return

[MON KEY <monkey@sandpframing.com>]

On Wed, Dec 8, 2010 at 2:28 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> MON KEY writes:
>  > On Tue, Dec 7, 2010 at 9:34 AM, Stephen J. Turnbull <stephen@xemacs.org> 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.
>

Is such an exercise so trivial a thing?

I recall there being a seminal series of paper written in the late
1970s with the short form titles matching the pattern:
 "Lambda the Ultimate .*"
e.g. the "The Lambda Papers" http://library.readscheme.org/page1.html

Note my use of the word "seminal" above. It was "left as an exercise"
to the now highly accomplished minds of CS to figure this out. I don't
pretend to understand/grasp or even have read much of what was
published on the topic. Should I assume this sort of stuff is obvious?

It apparently wasn't all that obvious for someone at DARPA circa
197[0-9] or they probably wouldn't have funded the work that produced
the deliverable largely responsible for the contemporary Lisps...

I would point out though that AI Memo 443[+] has an appendix section
entitled "Notes" with a subsection entitled "{Note Step Variables}" at
page 19 which discusses lexical scope and what might happen at runtime
with non-local exits inside a labeled recursive looping construct.

[+] Guy Lewis Steele, Jr.. "Debunking the "Expensive Procedure Call"
Myth, or Procedure Call Implementations Considered Harmful, or LAMBDA,
the Ultimate GOTO". ACM Conference Proceedings. October 1977.

>
>  > 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.

Most likely I am confused.

I don't see how `return', `return-from', `block', `tagbody', `go',
`unwind-protect', etc. can't not be affected by the `lexbind' nor how
their implementation in elisp (now or eventual) won't affect the
semantics of lambda/defun/defmacro.

> 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 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. :)

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.

> 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.
>

It is good to know that _you_ are sure, because apparently such
non-trivial issues as whether the lexbind will allow non-toplevel
defun's is not yet a "finalized" matter.

>  > 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.
>

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

What is clear (to me at least) is that CLTL2 pre-supposed changes to
Common Lisp which were sometimes subtle and sometimes not so subtle
ways. Moreover, given that the nearest contemporary lisp dialect to
Emacs lisp is Common Lisp (and this is the thrust of my concern) there
is a tremendously useful archive from the discussion of the CL ANSI
committee which addressed many of these issues and which I think
remain relevant to considerations w/re the lexbind.

I'm reasonably sure that only Miles/Stephan will have a hand in the
initial integration of the core of the lexbind with GNU Emacs, and
this will happen without too much discussion here. What I'm interested
to understand is how once that initial integration occurs others will
react, adapt, adjust, complain, lobby etc.

At the very least, the X3J13s formal discussion of and rationale for
how/why certain issues brought before them were resolved/addressed may
be able to inform future discussions re the elisp lexbind.

This is for example why I asked about use of &environment &whole.
There were more than one X3J13 votes around these.  See for example
"Issue &ENVIRONMENT-BINDING-ORDER Writeup" the CLHS.

From a CL perspective those issues often appear to have had an impact
on what happened w/ macroexpansion.

I find this both relevant and interesting w/re the GNU Emacs `lexbind'
and non-local exits because (as currently implemented in the lexbind
branch) it redefines what happens with `macroexpand' `macroexpand-all'
at compile time... this in turn influences `byte-compile-closure' and
`byte-compile-make-closure'.

It is left as an exercise for all of us to figure out how this stuff
will interact w/ things elisp's `define-modify-macro', `defsetf', etc.

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

This was never the crux of _my_ question.

As a reminder, apropos the YAGNI re an alternative elisp VM you tossed
out a caveatted example of defmacro'ing `lambda' by way of
defun/gensym, e.g.:

   ,----
   | (defmacro lambda (&rest forms) `(defun ,(gensym) ,@forms))
   |
   | or something like that. ;-)
   `----

My question was:

    "doesn't your example dance around what happens around
    defun/defmacro/lambda at compile time in any lexically scoped
    implementation of <substitute your non-interpreted lexically
    scoped modern lispy dialect of choice here>?"

>
> maintainers.  All three (code, requirement, making sense) must be
> present or your feature won't make it to the distributed Emacs.
>

There is no feature.

--
/s_P\