Re: Proposal: Forwards-Compatibility Library for Emacs

[Philip Kaludercic <philipk@posteo.net>]

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.

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.

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.

>         Stefan

-- 
	Philip Kaludercic