unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Daniel Hackney <dan@haxney.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	Emacs development discussions <emacs-devel@gnu.org>
Subject: RE: Lexical byte-compilation warnings cleanup
Date: Tue, 20 Aug 2013 19:57:49 -0700 (PDT)	[thread overview]
Message-ID: <9c9d5439-3ef5-44a3-b886-bc95bddec03a@default> (raw)
In-Reply-To: <87wqnfg675.fsf@uwakimon.sk.tsukuba.ac.jp>

>  >>>> Indeed, it does not refer to the dynamically bound variable.
>  >>> Why is that? Will this be fixed, or is this the intended design?
>  >> Intended design.
>  > And the intention is?  The design is?  The reason is?
> 
> Give it up, Drew.  RMS has never been one to prefer "a foolish
> consistency"

No one has argued for foolish consistency.  Or even for consistency
in this context.

> (ie, adherence to abstract principles)

Or for adherence to any abstract principles. 

> where consistency collides with his intuition or hacking convenience,
> and that same reliance on intuition appeals to current maintainers
> as well:

Nor has anyone argued against using intuition.  That can sometimes
be helpful.

But FWIW I don't think that RMS was particularly one to shy from
presenting his design choices explicitly and giving reasons for them.

Anyway, that was then and this is now - I don't see much point in
comparing with RMS here, either wrt the design or the process.  It's
not clear that RMS would have moved so quickly and cleanly toward
integrating lexical scoping - and I'm glad that has been done.

(No, sorry for the passive voice - I'm glad that Stefan did that.)

But I would like to understand more (more than zero, at least) about
the design intentions in this regard, and the reasons.

Since there are 35 years of big brother Common Lisp's experience
mixing lexical and dynamic binding in the same language, not to
mention years of high-level discussion by Lisp implementors of all
stripes to come up with that design in the first place, I would think
that doing something quite different would prompt at least some
discussion of alternatives, pros & cons, etc.

That was admittedly a long time ago, and no doubt knowledge and
technique have progressed since then.  All the more reason why I
would like to know something about what is behind this new approach.

Aren't you curious at all why this difference wrt function parameters?
That possibility never even occurred to me.  I'm sure there are some
reasons for the choices made, but they don't seem to be forthcoming.

>  > > As language designers, we just take idea from here and there.
> 
> I think that is the last word on Elisp design principles.  Abstractly
> I don't like it, myself, but surely you don't deny that it has proven
> to be a workable strategy.

Again, one can take ideas from here and there - no problem with that.
But one takes this idea instead of that one for a reason.  And that's
what I'm asking about.

Is it a good thing or a bad thing for more people to have an idea
what the design is about and what motivates it?

> Nevertheless there is hope for those who prefer care-full design:
> Guilemacs!

For the record, Guilemacs is not my hope.  (Not that I'm sure what
you mean by that term.)

So far, the addition of lexical scoping to Emacs has not been far
from the way it is mixed in with dynamic binding in Common Lisp,
AFAICT.  Naively, I would hope for Emacs Lisp to become more similar
in this regard, not more different.

But I'm no expert on any of this.  Which is why I asked the question.
And that's all I've done: ask why.

I ask it again: why?  The answer so far is to enable efficient
interpretation.  Sounds like that might be a promising reason, but
so far that slogan means nothing to me.

Does it mean something particular to you?  Don't you want to know
more about what is intended, and why, wrt this design which is
presumably so important to Emacs and Emacs-Lisp programmers?



  reply	other threads:[~2013-08-21  2:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19 23:33 Lexical byte-compilation warnings cleanup Daniel Hackney
2013-08-20  0:01 ` Juanma Barranquero
2013-08-20  0:11 ` Glenn Morris
2013-08-20  5:47 ` Stefan Monnier
2013-08-20 15:25   ` Drew Adams
2013-08-20 20:41     ` Stefan Monnier
2013-08-20 21:31       ` Drew Adams
2013-08-20 23:21         ` Stefan Monnier
2013-08-21  0:10           ` Drew Adams
2013-08-21  1:53             ` Stephen J. Turnbull
2013-08-21  2:57               ` Drew Adams [this message]
2013-08-21  4:49                 ` Stefan Monnier
2013-09-04 20:50                   ` Daniel Hackney
2013-09-15 19:33                   ` Daniel Colascione
2013-08-21  5:19       ` Dmitri Paduchikh
2013-08-21 20:12         ` Stefan Monnier
2013-09-05  3:30 ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2013-08-21 23:12 Barry OReilly
2013-08-22  5:05 ` Dmitri Paduchikh
2013-08-22 20:41   ` Stefan Monnier

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=9c9d5439-3ef5-44a3-b886-bc95bddec03a@default \
    --to=drew.adams@oracle.com \
    --cc=dan@haxney.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stephen@xemacs.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).