Re: Proposal: Forwards-Compatibility Library for Emacs

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>
>>>>> By its very nature it is an intrusive package, as it defines functions,
>>>>> macros and advice outside of the "namespace", but I don't see any way
>>>>> around that if transparent compatibility is to be provided (anything
>>>>> else would just replicate dash, s, f, ...).
>>>>
>>>> I think this uncleanliness is a bit risky.  Better put the definitions
>>>> in their own namespace.
>>>
>>> Just to be on the same page, what exactly is the risk? I understand the
>>> issue on a gut-level, it goes against convention and recommendations,
>>> but the idea is that this package would do that, so that others don't
>>> have to.
>>
>> It is not on a "gut-level" :). I was thinking about same, and wrote you a 
>> longer
>> answer I just sent. There were no replys when I started, I see now several
>> people replied.
>>
>> There can be two functions defineing slightly different behaviour in 
>> different
>> version, there can also be 3rd party packages expecting certain behaviour, 
>> and
>> there is no need to advise too much, say windowing code if application need 
>> to
>> just check is directory-empty-p.
>
> Yes, I think cases where different versions switch back and forth are
> hard to make compatible, so they should be left out of any attempt like
> this.
>
>>> Other than that, all the functions and macros are defined first using a
>>> "compat--" prefix, then perhaps are aliased to a symbol without a
>>> prefix.
>>>
>>>>  I don't think "transparent compatibility" is
>>>> worth the trouble here, and I don't think `s`, `f`, ... solve the
>>>> same problem.
>>>
>>> Of course not, s, f, and the rest of the dash-adjacent ecosystem have
>>> different intentions, it is only as a side effect that they provide more
>>> functionality than older versions of Emacs do.
>>
>> They define different API from Emacs, more used by people comming from 
>> different
>> Lisp(s), clojure if I am correct?
>
> From what I know they are inspired by Clojure and try to provide better
> compatibility with the various macros that dash provides (such as
> threading), but I am not sure if they are direct translations from
> Clojure's standard library.
>
>>> Most of the examples I provide in the file I attached above are simple
>>> or slower reimplementations that make programming more convenient, but
>>> where "transparent compatibility" becomes interesting is when providing
>>> noop compatibility that allows package developers to make use of newer
>>> features that are not backwards compatible, such as the additional
>>> interactive argument. The infrastructure doesn't exist to handle this
>>> information, but package developers will hold back from using these new
>>> features because they don't want to abandon all users that aren't on
>>> 28.1.
>>>
>>> I don't see how examples like these could be handled without transparent
>>> compatibility.
>>
>> When it comes to providing newly intoduced functionality, there shouldn't be 
>> a
>> problem, it should always be possible to just add a function, like
>> dired-empty-p:
>>
>>
>> (when (version< emacs-version "28")
>>   (defun directory-empty-p (file-name)
>>     "Check if a directory contains any other files then dot-files"
>>     (when (file-directory-p file-name)
>>       (null (directory-files file-name nil
>>                              directory-files-no-dot-files-regexp t)))))
>>
>> You don't even need to advise directory-files for that.
>
> That wouldn't even be advised. My definition
>
>     (compat-defun directory-empty-p (dir)
>       "Return t if DIR names an existing directory containing no other files.
>     Return nil if DIR does not name a directory, or if there was
>     trouble determining whether DIR is a directory or empty.
>
>     Symbolic links to directories count as directories.
>     See `file-symlink-p' to distinguish symlinks."
>       :version "28.1"
>       (and (file-directory-p dir)
>            (null (directory-files dir nil directory-files-no-dot-files-regexp 
> t))))
>
> is expanded to
>
>     (progn
>       (declare-function compat--directory-empty-p "compat"
>                         '(dir))
>       (let nil
>         (defun compat--directory-empty-p
>             (dir)
>           "[Compatibility function for `directory-empty-p', defined in Emacs 
> 28.1]\n\nReturn t if DIR names an existing directory containing no other 
> files.\nReturn nil if DIR does not name a directory, or if there was\ntrouble 
> determining whether DIR is a directory or empty.\n\nSymbolic links to 
> directories count as directories.\nSee `file-symlink-p' to distinguish 
> symlinks." nil
>           (and
>            (file-directory-p dir)
>            (null
>             (directory-files dir nil directory-files-no-dot-files-regexp t))))
>         (compat-ignore
>          (defalias 'directory-empty-p #'compat--directory-empty-p))))
>
> which is more or less the same as what you do (setting aside the fact
> that on my system, the installation via defalias is ignored).
Ah, ok, sorry I wasn't running any code; just so the advised directory-files and
that directory-empty-p used one with the counter. My bad.

>> But for already existing functions that might lead to problems. I think so at
>> least. In the answer I sent you, I was thinking of buffer-local function
>> variables instead of advices which are global.