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: Mon, 6 Dec 2010 21:42:06 -0500 Message-ID: References: <87mxojwu15.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4jnweng.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 1291689743 29419 80.91.229.12 (7 Dec 2010 02:42:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Dec 2010 02:42:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 07 03:42:19 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 1PPnVS-0006DN-1W for ged-emacs-devel@m.gmane.org; Tue, 07 Dec 2010 03:42:18 +0100 Original-Received: from localhost ([127.0.0.1]:52877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPnVQ-0002fI-U9 for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2010 21:42:16 -0500 Original-Received: from [140.186.70.92] (port=53345 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPnVL-0002dY-PW for emacs-devel@gnu.org; Mon, 06 Dec 2010 21:42:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPnVJ-0000Qm-Kr for emacs-devel@gnu.org; Mon, 06 Dec 2010 21:42:11 -0500 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:65535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPnVJ-0000QW-5C for emacs-devel@gnu.org; Mon, 06 Dec 2010 21:42:09 -0500 Original-Received: by wwb17 with SMTP id 17so4913418wwb.30 for ; Mon, 06 Dec 2010 18:42:07 -0800 (PST) Original-Received: by 10.216.238.130 with SMTP id a2mr5838723wer.28.1291689726764; Mon, 06 Dec 2010 18:42:06 -0800 (PST) Original-Received: by 10.216.70.212 with HTTP; Mon, 6 Dec 2010 18:42:06 -0800 (PST) In-Reply-To: <87k4jnweng.fsf@uwakimon.sk.tsukuba.ac.jp> X-Google-Sender-Auth: IjIPG2bOsB5R3QLSjqEjQjuqycY 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:133482 Archived-At: On Mon, Dec 6, 2010 at 2:20 AM, Stephen J. Turnbull wrote: > MON KEY writes: > > > Indeed, one often doesn't miss what one never knew wasn't there to be missed. > > GVM has no doubt leveraged this against future Python initiates. > > > Not at all. Python is intended to have functional programming > features, but it's also intended to primarily be an imperative > language, not a functional language. GvR is well aware of the uses of > lambda and there are a lot of fans of lambda (as well as of "first- > class anonymous blocks" which may or may not be the same as lambdas) > among Pythonistas. He just doesn't think such features belong in > Python, and I have to admit I don't miss them. > I'e no clue whether this is good or bad for Python(istas) my concern is simply that this viewpoint not encroach upon the Emacs Lisp VM without qualification. :) In any event, AIUI much of GvR's objection w/re Python's lambda was that it won't parse cleanly given the syntactic reliance on whitespace. Whichever, I was mostly pointing out that with lisp source we don't rely on whitespace to formally convey syntax and that (with lisp2's at least) there is ample opportunity to make use of imperative style block/go/return/return-from forms as well... No doubt this is obvious to most here but it is all too easily forgotten when discussion of alternative non-lispy languages are brought to bare on the efficacy of lispy languages. > > > ,---- > > | (defmacro lambda (&rest forms) `(defun ,(gensym) ,@forms)) > > | > > | or something like that. ;-) > > `---- > > > > Perhaps, but quite a bit more happens at compile time around lambda and will do > > more so if/when the lexbind is merged. :) > > That was a wink because of course I'm cheating like hell: in a typical > interpreted Lisp, defun is just a feature-creepy way of associating a > lambda with a name (aka symbol), and my macro is an inefficient way of > creating an anonymous function. Likely you know better than I and the wink wasn't lost on me. :) However, as you suggest with your caveat "in a typical interpreted Lisp" this may not apply to compiled code... Which is to say, doesn't your example dance around what happens around defun/defmacro/lambda at compile time in any lexically scoped implementation of ? > IOW, no, nothing special happens at > compile time and no, lexbind won't change that. Any semantic changes > that happen to lambda will happen to defun and vice versa. > > > What would be interesting to learn is whether there is any will for a formal > > incorporation of the C in Clisp w/ the E in elisp? > > {...} > Hrvoje Niksic and Martin Buchholz advocated a Common Lisp as the > appropriate way to evolve elisp, and IIRC Erik Naggum was in that camp > too. But they've all long since left the development community. The slime users/developers are _actively_ incorporating Common Lisp (of various implementations) with Emacs/Emacs lisp (unfortunately they have to resort to a different RPC per implementation to do so). Regardless, the Slime user/devel community is hardly an insignificant group. This said, I suspect most of them only actively engage elisp in lieu of Common Lisp out of necessity not preference. > > I think most of the people with an interest in it are either hacking > elisp directly (like Miles) or are Schemers (like Mike "R6RS" > Sperber). > Don't forget the Guile Schemers whose efforts to incorporate the R6RS with that implementation will eventually bring yet another Scheme that much closer to Greenspun's 10th... In which case, assuming further future integration of Guile with (GNU) Emacs we might find that much of what the Common Lisp crowd has sought for years will (finally) be made available to the Emacs VM. If such does happen, it will be highly amusing to witness the clamor by Schemers for elisp incorporation of `#:keywords-styled-thusly' esp. when these too are dismissed as "ugly" , "inefficient to implement", "confusing to users", etc. Meanwhile burgeoning adepts of the GNU Findutils toolbox will no doubt chuckle nervously at the thought of trying to invoke a `find' command (with its 70+ flags) with only "By Order of Argument" at their disposal... > > > the closed/proprietary control maintained on the FSF Emacs source > > tree. > > Hardly closed *or* proprietary. Tomato/Potato[1] > Remember XEmacs in your prayers, and > rest assured that any work you do on Emacs remains free for others to > use, whether GNU chooses to distribute it or not. No doubt. :) > If they choose not, you can always do it yourself, as we do. Yes but there is an accord to maintain some mutual consensus. AIUI your presence on this list is indicative of such an effort no? To paraphrase JWZ, "Now you have two problems." > > But ... I wouldn't bet that you'll have more luck peddling your warez > at xemacs.org or sxemacs.org for that matter. > I'm not aware of peddling either here or there... what is occurring here is more akin to carpet-bagging than to commerce in snake-oil. > > That's the nature of a distribution, that somebody decides what to distribute. > Typically by rejecting your proposals, c'est la vie. :-) > If there is angst here it is not around the rejection of any particular proposal (certainly not my own), but rather about the persistent inability to engage in reasoned/meaningful/intentioned discussion w/re incorporating of a particular set of Lisp features by either ignoring and/or dismissing the utility these features do otherwise provide both Emacs user community and the greater community of Lisp dialect users despite a general acknowledgment by both of these communities that the particular set of features are wanted/needed and FTMP can be reasonably implemented. [1] The long term evidence of this inability IMO suggests that the Emacs project(s) are closed and proprietary project (whether their source be free or not). That [SX]Emacs does remain reasonably compatible with GNU Emacs suggest that it too abides this inability (whether tacitly or otherwise). -- /s_P\