From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Drew Adams <drew.adams@oracle.com>
Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,
Daniel Hackney <dan@haxney.org>,
Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: Lexical byte-compilation warnings cleanup
Date: Wed, 21 Aug 2013 00:49:22 -0400 [thread overview]
Message-ID: <jwvli3vmzj5.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <9c9d5439-3ef5-44a3-b886-bc95bddec03a@default> (Drew Adams's message of "Tue, 20 Aug 2013 19:57:49 -0700 (PDT)")
>> > And the intention is? The design is? The reason is?
Check the calling convention used by the new byte-code representation
(used for lexically scoped code) and you'll see that there's no support
for dynamic scoping in it. Adding such support "natively" would
slow down the common case too much.
We could support dynamically-scoped args in lexically-scoped byte-code
by tweaking the byte-compiler, but then the byte-code that the
byte-compiler needs to generate is the same as the one you get with:
(defun foo (lexarg)
(let ((dynvar lexarg))
...))
So I prefer to make the extra cost of the separate `let' binding
explicit in the source code. Especially since it has various beneficial
side-effects:
- simpler byte-compiler.
- slightly more efficient handling of function calls for
lexically-scoped interpreted code (this is actually less beneficial
than I thought at first, tho).
- IMNHO better style (I have always found it confusing when dynvars were
bound as function arguments rather than by a let-binding).
- having a separate `let' often allows you to move it to a better place,
and/or to add useful code between the function header and the let
binding (such as the defvar that causes the variable to be
dynamically bound).
BTW, I have never seen a dynamically-scoped argument used in
Common Lisp.
Stefan
next prev parent reply other threads:[~2013-08-21 4:49 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
2013-08-21 4:49 ` Stefan Monnier [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvli3vmzj5.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=dan@haxney.org \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.