alist-get in Emacs 24?

alist-get in Emacs 24?

[Marcin Borkowski]

Hi all,

some time ago, someone here recommended the alist-get function to me.
It works like a charm for me, but not for some other user who's running
Emacs 24.

While writing (or copying from subr.el) an alist-get "getter" version is
trivial, the "setter" version (which I need for setf, cl-incf and
cl-decf) is a bit harder for me.  Looking at

(gv-define-expander alist-get ...)

in gv.el makes my head explode.  I will probably just write functions
like set-alist-element and inc-alist-element (or maybe I'll name them
better) so that the library works in Emacs 24, but is there a better
way?  (Note: while I'm fairly confident that I could understand that
gv-define-expander stuff, it would probably take a lot of time.  This is
the long-term plan.  Now my goal is to help that user ASAP.)

Also, what would be the recommended policy for supporting older Emacsen?
Is it enough to test my packages against 24.1 (which didn't compile on
my machine anyway, btw)?  Should I care for Emacs 23 at all?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: alist-get in Emacs 24?

[Dmitry Gutov]

On 10/02/2015 09:32 AM, Marcin Borkowski wrote:

> some time ago, someone here recommended the alist-get function to me.
> It works like a charm for me, but not for some other user who's running
> Emacs 24.

Why not use assoc-default?

Re: alist-get in Emacs 24?

[Marcin Borkowski]

On 2015-10-02, at 08:39, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 10/02/2015 09:32 AM, Marcin Borkowski wrote:
>
>> some time ago, someone here recommended the alist-get function to me.
>> It works like a charm for me, but not for some other user who's running
>> Emacs 24.
>
> Why not use assoc-default?

Does it work with setf?

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: alist-get in Emacs 24?

[Michael Heerdegen]

Marcin Borkowski <mbork@mbork.pl> writes:

> I will probably just write functions like set-alist-element and
> inc-alist-element (or maybe I'll name them better) so that the library
> works in Emacs 24, but is there a better way?

There was assoc.el in prior Emacsen (and it's still lying around in
lisp/obsolete).  `aput' is its setter for alists.  Works great, but is
obsolete.

A different approach is to use `assoc', `delq' and `push', i.e., do it
by hand.

> Also, what would be the recommended policy for supporting older Emacsen?
> Is it enough to test my packages against 24.1 (which didn't compile on
> my machine anyway, btw)?  Should I care for Emacs 23 at all?

That's your choice.  There are lots of third party packages that only
support the current minor release and maybe some before that.  Others
support much older releases.

Support of old releases is nice for people that have to use the Emacs
version they find at their computer at work.  In your case, if you don't
even know those older releases much, I would not care too much about it.


Michael.

Re: alist-get in Emacs 24?

[Marcin Borkowski]

On 2015-10-02, at 09:34, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I will probably just write functions like set-alist-element and
>> inc-alist-element (or maybe I'll name them better) so that the library
>> works in Emacs 24, but is there a better way?
>
> There was assoc.el in prior Emacsen (and it's still lying around in
> lisp/obsolete).  `aput' is its setter for alists.  Works great, but is
> obsolete.

Thanks.

> A different approach is to use `assoc', `delq' and `push', i.e., do it
> by hand.

And this might be the way to go for me.

>> Also, what would be the recommended policy for supporting older Emacsen?
>> Is it enough to test my packages against 24.1 (which didn't compile on
>> my machine anyway, btw)?  Should I care for Emacs 23 at all?
>
> That's your choice.  There are lots of third party packages that only
> support the current minor release and maybe some before that.  Others
> support much older releases.

Of course.  What I was asking was more or less "what is the percentage
of Emacs users who are on 23, 24... etc.".  Are there any estimates?

Also, are there any good practices/guidelines as to how to indicate in
the code that some of its parts are meant for legacy Emacsen?  So that
I can e.g. remove them 3 years from now without having to study all the
code, for example.

> Support of old releases is nice for people that have to use the Emacs
> version they find at their computer at work.  In your case, if you don't
> even know those older releases much, I would not care too much about it.

I know quite a lot about those releases - I started with Emacs v19 or
so.  It's that I know about them only from the user perspective;
I started serious Elisp hacking about v23.

Also, assuming everyone else also is on the bleeding edge and compiles
from source is not a brilliant idea, I admit.

> Michael.

Thanks again,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: alist-get in Emacs 24?

[Michael Heerdegen]

Marcin Borkowski <mbork@mbork.pl> writes:

> Of course.  What I was asking was more or less "what is the percentage
> of Emacs users who are on 23, 24... etc.".  Are there any estimates?

Good question.

> Also, are there any good practices/guidelines as to how to indicate in
> the code that some of its parts are meant for legacy Emacsen?  So that
> I can e.g. remove them 3 years from now without having to study all the
> code, for example.

Most people that want to support older Emacs versions do it like this
in their code:

(if (test-if-a-certain-feature-is-implemented)
    ;; Emacs >= 25.1
    (code for newer Emacs versions ...)
  ;; Emacs < 25
  (code for older Emacs versions))


Regards,

Michael.

Re: alist-get in Emacs 24?

[Stefan Monnier]

> There was assoc.el in prior Emacsen (and it's still lying around in
> lisp/obsolete).  `aput' is its setter for alists.  Works great, but is
> obsolete.

"Works great" only if your needs are very modest.  E.g. it's
terribly inefficient, and it relies on dynamic scoping.

As for the (gv-define-expander alist-get ...), you could just blindly
copy that definition into your package.  Of course that'll only work for
Emacsen with gv.el.  For older Emacsen, you'll have to use
define-setf-expander, which indeed works a bit differently from
gv-define-expander.  For the very reason that I invented
gv-define-expander, I'd rather not try and come up with the equivalent
define-setf-expander.


        Stefan

Re: alist-get in Emacs 24?

[Marcin Borkowski]

On 2015-10-02, at 09:34, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I will probably just write functions like set-alist-element and
>> inc-alist-element (or maybe I'll name them better) so that the library
>> works in Emacs 24, but is there a better way?
>
> There was assoc.el in prior Emacsen (and it's still lying around in
> lisp/obsolete).  `aput' is its setter for alists.  Works great, but is
> obsolete.
>
> A different approach is to use `assoc', `delq' and `push', i.e., do it
> by hand.

OK, so I did it by hand (though without delq or push).  I am not
extremely happy with my solution, though, since in the setter function
I have to pass the alist variable name as a symbol.  (This is needed
because I might want to use it to introduce a new key-value pair into
the list.)  Does anyone have any suggestion for enhancing my solution?

--8<---------------cut here---------------start------------->8---
(require 'cl)

(defun my-alist-get (key alist)
  "Return the value associated to KEY in ALIST.
This function is needed for Emacsen older than v25."
  (cdr (assoc key alist)))

(defun my-set-alist-value (key alist value)
  "Set the value corresponding to KEY in ALIST to VALUE.
Note: ALIST should be a symbol.  This is morally equivalent to
`(setf (alist-get key (symbol-value alist)) value)',
but works in older Emacsen."
  (let ((pair (assoc key (symbol-value alist))))
    (if pair
	(setcdr pair value)
      (set alist (acons key value (symbol-value alist))))))

(defun my-inc-alist-value (key alist increment)
  "Increment the value corresponding to KEY in ALIST by INCREMENT.
Throw an error if KEY is not in ALIST."
  (let ((pair (assoc key alist)))
    (if pair
	(incf (cdr pair) increment)
      (error "Nothing to increment"))))
--8<---------------cut here---------------end--------------->8---

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: alist-get in Emacs 24?

[Drew Adams]

> I have to pass the alist variable name as a symbol.  (This is needed
> because I might want to use it to introduce a new key-value pair
> into the list.)  Does anyone have any suggestion for enhancing my
> solution?
> 
> (defun my-set-alist-value (key alist value)
>   "Set the value corresponding to KEY in ALIST to VALUE.
> Note: ALIST should be a symbol.  This is morally equivalent to
> `(setf (alist-get key (symbol-value alist)) value)',
> but works in older Emacsen."
>   (let ((pair (assoc key (symbol-value alist))))
>     (if pair
> 	(setcdr pair value)
>       (set alist (acons key value (symbol-value alist))))))

You say that ALIST must be a symbol here, but I don't see why.
Why not just modify the alist structure (i.e., the alist) itself?
Why repoint the variable to the result inside the set function?

If you modify the structure in place, and you return the new alist,
then you can always do this to ensure that the variable is up-to-date:
(setq THE-VAR (my-set-alist-value key alist value))

That's typically the way destructive operations are done.  It is
why you need to do (setq foo (delete 42 foo)).

Re: alist-get in Emacs 24?

[Michael Heerdegen]

Marcin Borkowski <mbork@mbork.pl> writes:

> OK, so I did it by hand (though without delq or push).  I am not
> extremely happy with my solution, though, since in the setter function
> I have to pass the alist variable name as a symbol.  (This is needed
> because I might want to use it to introduce a new key-value pair into
> the list.)  Does anyone have any suggestion for enhancing my solution?

First let me say, doing it like that is not bad in any regard.

Second, yes, you could modify the list structure, but this can't be done
if the alist is empty, because the empty (a)list is not a cons.  At least
in this case, your setter would still have to receive a symbol.


Michael.

RE: alist-get in Emacs 24?

[Drew Adams]

> Second, yes, you could modify the list structure, but this can't be
> done if the alist is empty, because the empty (a)list is not a cons.
> At least in this case, your setter would still have to receive a symbol.

I don't see it that way.  How is this different from defining
`delete' or any of the other structure potentially-modifying
functions?  None of those functions require you to pass a symbol
argument.  The only function I can think of offhand that does
that is `add-to-list'.  Its more common (and generally more useful)
cousins, `push' and `pushnew' don't do that.

Yes, with such (destructive) functions, if you have a variable
pointing to the list (empty or not), you do need to re-set it
to the result returned by the function.  But that's all, AFAIK.

As I said (examples):
 (setq THE-VAR (my-set-alist-value key alist value))
 (setq foo (delete 42 foo))

Re: alist-get in Emacs 24?

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Yes, with such (destructive) functions, if you have a variable
> pointing to the list (empty or not), you do need to re-set it
> to the result returned by the function.  But that's all, AFAIK.

Our views just differ in whether you think of a `setter' as already
including the above (undoubtedly necessary) "res-set" operation or not.
I understood "setter" as the term is used for (generalized) variables
like in gv.el.

What I meant is that just passing by value is not sufficient, you have
to set a symbol's value somewhere.  With regard to that, no, this is not
different from `delete'.


Michael.