emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Return


From: Stephen J. Turnbull
Subject: Re: Return
Date: Mon, 06 Dec 2010 16:20:51 +0900

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.

 > ,----
 > | (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.  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.  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).

 > the closed/proprietary control maintained on the FSF Emacs source
 > tree.

Hardly closed *or* proprietary.  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.  If they choose not,
you can always do it yourself, as we do.

But ... I wouldn't bet that you'll have more luck peddling your warez
at xemacs.org or sxemacs.org for that matter.  That's the nature of a
distribution, that somebody decides what to distribute.  Typically by
rejecting your proposals, c'est la vie. :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]