[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: Conditional binding and testing of `lexical-binding
From: |
LdBeth |
Subject: |
Re: [External] : Re: Conditional binding and testing of `lexical-binding' |
Date: |
Mon, 03 Jan 2022 11:09:47 +0800 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-apple-darwin18.7.0) MULE/6.0 (HANACHIRUSATO) |
>>>>> 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
Re: Conditional binding and testing of `lexical-binding', Stefan Monnier, 2022/01/02