From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Return Date: Wed, 8 Dec 2010 13:11:34 -0500 Message-ID: References: <87mxojwu15.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4jnweng.fsf@uwakimon.sk.tsukuba.ac.jp> <87d3pdwt1x.fsf@uwakimon.sk.tsukuba.ac.jp> <87wrnkvi3t.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1291960313 24354 80.91.229.12 (10 Dec 2010 05:51:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Dec 2010 05:51:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 10 06:51:49 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PQvtV-0005t3-3q for ged-emacs-devel@m.gmane.org; Fri, 10 Dec 2010 06:51:49 +0100 Original-Received: from localhost ([127.0.0.1]:38825 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQgrG-0008Vv-Uj for ged-emacs-devel@m.gmane.org; Thu, 09 Dec 2010 08:48:31 -0500 Original-Received: from [140.186.70.92] (port=36353 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQOUL-0001Xf-PJ for emacs-devel@gnu.org; Wed, 08 Dec 2010 13:11:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQOUK-00025g-6h for emacs-devel@gnu.org; Wed, 08 Dec 2010 13:11:37 -0500 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:64673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQOUJ-000250-Qe for emacs-devel@gnu.org; Wed, 08 Dec 2010 13:11:36 -0500 Original-Received: by wyj26 with SMTP id 26so1453181wyj.0 for ; Wed, 08 Dec 2010 10:11:34 -0800 (PST) Original-Received: by 10.216.184.139 with SMTP id s11mr199638wem.13.1291831894210; Wed, 08 Dec 2010 10:11:34 -0800 (PST) Original-Received: by 10.216.70.212 with HTTP; Wed, 8 Dec 2010 10:11:34 -0800 (PST) In-Reply-To: <87wrnkvi3t.fsf@uwakimon.sk.tsukuba.ac.jp> X-Google-Sender-Auth: uvIPCvIfJMQXxrF3kFQk2WiyYF0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133562 Archived-At: On Wed, Dec 8, 2010 at 2:28 AM, Stephen J. Turnbull wrote: > MON KEY writes: > > On Tue, Dec 7, 2010 at 9:34 AM, Stephen J. Turnbull 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 ?" > > 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\