unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>, "'Thien-Thi Nguyen'" <ttn@gnuvola.org>
Cc: emacs-devel@gnu.org
Subject: RE: Emacs and Guile
Date: Wed, 11 Apr 2012 10:28:46 -0700	[thread overview]
Message-ID: <03C7784776094A39B734257DFBE804C5@us.oracle.com> (raw)
In-Reply-To: <83bomy5vc0.fsf@gnu.org>

I do not want to get into this discussion in detail (and don't bother flaming).
Just count me as one voice who is not in favor of "basing" Emacs on Guile or any
other Scheme dialect or implementation.

I might not object to "basing" Emacs on Common Lisp.  I think that Common Lisp,
like Emacs Lisp, is a much better fit for the kind of programming, including
customization and UI, that Emacs users and developers do.

I am content with Emacs being Emacs Lisp.  (Yes, I said "being", and not just
"being based on", because I view Emacs Lisp as part and parcel of Emacs, not
just as its implementation language.)  But I would not mind Emacs Lisp moving
more toward some of what Common Lisp offers.  (I also generally appreciate it
when we move some stuff from C to Lisp.)

I am strongly in favor of both lexical and dynamic binding/scope, for the usual
reasons given for each.

I have been in favor of lexical binding for Lisp since the original Lambda
papers back in the 70s & 80s (http://library.readscheme.org/page1.html).  But
that does not mean that I am in favor of a Scheme-based Emacs.

[I am a functional (and logic, and constraint) programming fan too, but I am not
in favor of a Haskell-based Emacs.  (I am not opposed to experimentation.  I
just do not want to see Emacs lose its Lisp development/base.)]

In the case of Emacs and its Lisp use cases, RMS's description of the advantages
of dynamic binding is right on
(http://www.gnu.org/software/emacs/emacs-paper.html#SEC17,
http://www.gnu.org/software/emacs/emacs-paper.html#SEC18), and too often missed
or under-appreciated, I think.

Steve Yegge, for example, gives as his only example of dynamic-scope advantage
setting a free variable in a called function to affect the caller's stack frame
(http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html).  The advantage
to be emphasized is instead the one RMS points out: binding/setting in a caller
to affect callee behavior.

It would be misguided, IMHO, to move to a Lisp that did not enjoy both lexical
and dynamic binding/scope as first-class features.

That's all I want to say on the matter.  No, I did not provide much in the way
of reasons - I'm not really interested in the discussion.  Just count me as one
vote against a Guilemacs.  I want a "real" Lisp for Emacs ;-).  (Sorry, couldn't
resist.)




  reply	other threads:[~2012-04-11 17:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-09 22:28 GSoC projects related to Emacs Bastien
2012-04-03  3:36 ` Leo
2012-04-10  7:09   ` Emacs and Guile (was: GSoC projects related to Emacs) Eli Zaretskii
2012-04-10  8:26     ` Emacs and Guile Werner LEMBERG
2012-04-10 10:09       ` Eli Zaretskii
2012-04-10 12:17         ` Werner LEMBERG
2012-04-10 23:06     ` Leo
2012-04-11  6:55       ` Eli Zaretskii
2012-04-10 23:57     ` BT Templeton
2012-04-11  7:29       ` Eli Zaretskii
2012-04-11 11:31         ` Thien-Thi Nguyen
2012-04-11 12:03           ` Eli Zaretskii
2012-04-11 17:28             ` Drew Adams [this message]
2012-04-11 19:15               ` BT Templeton
2012-04-11 21:18                 ` Drew Adams
2012-04-13  4:06           ` Richard Stallman
2012-04-13  7:32             ` Thien-Thi Nguyen
2012-04-13  7:43               ` Miles Bader
2012-04-22 15:12                 ` Thien-Thi Nguyen
2012-04-11 17:00     ` Andy Wingo
2012-04-12  9:34     ` Emacs and Guile (was: GSoC projects related to Emacs) Ken Raeburn
2012-04-10  2:23 ` GSoC projects related to Emacs Stefan Monnier
2012-04-10  7:10   ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=03C7784776094A39B734257DFBE804C5@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ttn@gnuvola.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).