Re: [External] : Re: Conditional binding and testing of `lexical-binding'

[LdBeth <andpuke@foxmail.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