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: Fri, 26 Nov 2010 18:01:49 -0500 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1290812531 825 80.91.229.12 (26 Nov 2010 23:02:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Nov 2010 23:02:11 +0000 (UTC) Cc: larsi@gnus.org, Tassilo Horn , Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 27 00:02:06 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 1PM7Iq-0000Zb-9G for ged-emacs-devel@m.gmane.org; Sat, 27 Nov 2010 00:02:04 +0100 Original-Received: from localhost ([127.0.0.1]:53319 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PM7Ip-00020e-6A for ged-emacs-devel@m.gmane.org; Fri, 26 Nov 2010 18:02:03 -0500 Original-Received: from [140.186.70.92] (port=45240 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PM7Ig-0001zE-Jq for emacs-devel@gnu.org; Fri, 26 Nov 2010 18:01:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PM7Ie-0002yG-73 for emacs-devel@gnu.org; Fri, 26 Nov 2010 18:01:54 -0500 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:35103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PM7Ie-0002y0-2w for emacs-devel@gnu.org; Fri, 26 Nov 2010 18:01:52 -0500 Original-Received: by wwj40 with SMTP id 40so188227wwj.30 for ; Fri, 26 Nov 2010 15:01:51 -0800 (PST) Original-Received: by 10.216.172.149 with SMTP id t21mr699134wel.43.1290812509849; Fri, 26 Nov 2010 15:01:49 -0800 (PST) Original-Received: by 10.216.70.212 with HTTP; Fri, 26 Nov 2010 15:01:49 -0800 (PST) X-Google-Sender-Auth: Fqx5Ir4QULxSVb3KxczfemRjF8I 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:133180 Archived-At: > just out of inertia but also because I like a more functional style > of programming: usually/often you can find a formulation that's just > as elegant without the need for an early exit. I don't see how (of itself) this preference is sufficiently applicable. W/re the current inertia of the Emacs lisp VM, it seems whatever "elegance" gained by the "functional" style it provides is per the dynamic scoping, and even so it still _requires_ dynamic non-local exits with catch/throw. How do you anticipate reconciling this preference in terms of lexbind integration? The impression I'm given from the CL ANSI spec is that the `block'/`return-from' special forms (despite their "non-elegance") were desirable/needed in lieu of dynamic shadowing other dynamic shadowing concerns w/re transfer of control on exit, e.g. Section 3.1.5 "Shadowing" of the Common Lisp ANSI spec: (URL `http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_3-1-5.html') Note, in particular that the above should not be considered without consideration of the impact this hs w/re to Common Lisps treatment of Closures and Lexical Binding e.g. the immediately preceding section 3.1.4. and the X3J13 Exit Extent Issue: ,---- | | The extent of an exit is not the same thing as the scope of the | designator by which the exit is identified. For example, a BLOCK | name has lexical scope but the extent of its exit is dynamic; the | scope of a CATCH tag could differ from the extent of the CATCH's | return point. (That's part of what is at issue here.) | `---- :SEE (URL `http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Issues/iss152-writeup.html') In reading the second link above it's pretty clear that this issue had an immediate affect on `unwind-protect'. Indeed, to the extent :P this is so, discussion/dismissals of block/return-from should take into the historic tension between Maclisp derived lisps dialects and the Scheme derived lisp dialects around `unwind-protect'. IOW, It almost certainly wasn't simply as a matter of personal preference that the Common Lisp people incorporated and subsequently debated the correct implementation of the things. > We could also provide (and encourage the use of) Scheme's named-let, > although it tends to be "too powerful" (not inherently > tail-recursive, so making it efficient (CPU-wise and > stack-space-wise) would require a good bit more work). So, how then is `named-let' a somehow better/cleaner solution than an alternative first-class implementation of a `block'/`return-from' regime? -- /s_P\