From: LdBeth <andpuke@foxmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: LdBeth <andpuke@foxmail.com>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: [External] : Re: Conditional binding and testing of `lexical-binding'
Date: Mon, 03 Jan 2022 11:09:47 +0800 [thread overview]
Message-ID: <tencent_B9F73F1CB7BD6E46C7D31E078C741D4CAB07@qq.com> (raw)
In-Reply-To: <SJ0PR10MB548898B6BA9D69C29FABB6A9F3489@SJ0PR10MB5488.namprd10.prod.outlook.com>
>>>>> In
<SJ0PR10MB548898B6BA9D69C29FABB6A9F3489@SJ0PR10MB5488.namprd10.prod.outlook.com>
>>>>> Drew Adams <drew.adams@oracle.com> wrote:
>> > (if (and (boundp 'lexical-binding)
>> > lexical-binding)
>> > (lambda (y) (something x y))
>> > `(lambda (y) (something ',x y)))
>>
>> You may use `static-if' to benifit from
>> byte-compiling.
> I see no `static-if' in any Emacs release, from
> emacs -Q. (The most recent Emacs release is 27.2.)
> Certainly it's not present in Emacs 23 or earlier,
> which is where there's no variable `lexical-let'.
> So clearly it can't be used in Emacs 23 to test
> whether lexical binding is supported.
It's a macro from APEL, so sorry for not making it clear
that it is not part of Emacs.
But I thought it would be helpful because it seems
you want to take the advantages of speed gain via byte
compiling.
APEL is a library that supports Emacs versions as
old as 18 or XEmacs.
https://directory.fsf.org/wiki/Apel
This is the definition of `static-if' macro.
```
(put 'static-if 'lisp-indent-function 2)
(defmacro static-if (cond then &rest else)
"Like `if', but evaluate COND at compile time."
(if (eval cond)
then
`(progn ,@ else)))
```
> I wonder whether you might have misread my post.
> This is about a library that intends to be usable
> with Emacs releases prior to Emacs 24 (where that
> var is introduced), as well as with later Emacs
> releases.
> This is not about _converting_ a library to always
> use `lexical-binding', which would only be useful
> for Emacs 24 and later.
> It's about being able to take advantage of
> `lexical-binding' for Emacs 24+, while still being
> compatible with versions earlier than 24.
>> > But my question is really about conditionally
>> > _setting_ `lexical-binding', so it can be tested.
>>
>> I think the "lispy" way is to use:
>> (provide 'lexical-binding)> and use `featurep' to test it.
> See above, or reread my first post. (And none of
> my code is providing feature `lexical-binding'.
> Just setting that var to t does not "provide" it
> as a supported feature. It's either supported by
> a given version of Emacs or it's not.)
>> A more reliable way
> To do what? This apparently has nothing to do
> with the quoted text it followed (?).
>> is to test
>> (static-if (assoc 'lexical-binding (buffer-local-variables))
>> (provide 'lexical-binding))
>> instead of doing `boundp' test.
> Sorry, but that makes no sense to me. Emacs
> support for `lexical-binding' is true (for
> Emacs 24+) regardless of whether that var is
> buffer-local variable (and with any value).
Sorry for I was making that conclusion based on
the wrong assumption about how buffer local
variables works.
But I think instead of testing whether `lexical-binding'
has been bound,
```
(if (>= emacs-major-version 24)
(provide 'lexical-binding))
```
testing major version number seems to be easier since
it is unlikely someone would take an old version of
Emacs and patch for lexical binding only, or use a
version above 24 but taking out the lexical binding
support.
And instead of doing the lexical binding support test
in every file, having the `provide' statement in one
file loaded before any other files and use `featurep'
as a universal test of that feature seems to be more
appropriate.
>> > Is this the thing to do? If not, what advice
>> > do you have for adapting a library to use
>> > lexical binding when available (Emacs 24+) but
>> > to also work when it's unavailable (Emacs < 24)?
>>
>> > [The doc just tells you how to convert code to
>> > use lexical binding. I see nothing about how
>> > to code compatibly for old and new Emacs.]
>>
>> Well, I think it's fine to just keep that library as-is.
>> Even in the current lastest release there are still many
>> builtin packages are not converted to using lexical binding
>> at all. Just name a few I know, supercite, enriched-mode
> Certainly it's OK to keep such a library as is.
> I've been doing that for years.
> But I'm asking how to let it take advantage of
> lexical binding when that's available. That's
> the question I posed. I said how I intend to
> do that, but I asked if there's a better way.
I apologize again for not reading your post carefully.
However, as Stefan says, what lexical-binding provides
is "nothing ground breaking", even you've already
hit a critical performance bottle neck, converting
to lexical binding would help little.
In my opinion, adopting lexical-binding is mainly
for making the code cleaner. Having both lexical
binding and dynamic binding in one library, seems
to be contrary to that goal.
--
LDB
next prev parent reply other threads:[~2022-01-03 3:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-01 22:24 Conditional binding and testing of `lexical-binding' Drew Adams
2022-01-02 12:36 ` LdBeth
2022-01-02 12:41 ` Po Lu
2022-01-02 18:29 ` Stefan Monnier
2022-01-02 23:01 ` [External] : " Drew Adams
2022-01-02 23:01 ` Drew Adams
2022-01-03 0:49 ` Po Lu
2022-01-02 23:01 ` Drew Adams
2022-01-03 3:09 ` LdBeth [this message]
2022-01-03 3:31 ` Drew Adams
2022-01-02 18:27 ` Stefan Monnier
2022-01-02 23:01 ` [External] : " Drew Adams
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=tencent_B9F73F1CB7BD6E46C7D31E078C741D4CAB07@qq.com \
--to=andpuke@foxmail.com \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.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).