bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST function

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST function

Lars Ingebrigtsen
Drew Adams <[hidden email]> writes:

> Please consider adding a TEST comparer arg for plist keys.
>
> In Elisp, a plist key need not be a symbol:
>
> (plist-put (list "aaa" 1 "bbb" 2 "ccc" 3) "bbb" 42)
>
> That "works" (and no error), but it doesn't do what's expected, since
> the keys should be compared with `equal' or `string=', not `eq'.

plist-put doesn't ensure that the operation makes sense here, no, but we
can't really add that at this point, either.

I think adding a comparison function makes sense, but on the other
hand -- we seem to be moving towards using map.el more for these things
now, so I'm not sure there's much enthusiasm for that.  On the other
hand, the generic map functions have the problem that they...  can't
really be used like plist-put.  Sure

(map-put! (list 'a 1) 'b 2)

works fine, but you can't create a plist that way, which makes these
functions barely usable at all for handling plists/alists:

(map-put! nil 'b 2)

will signal an error.

So does anybody have an opinion here?  I think I'm in favour of adding a
comparison function for all three `plist-*' functions.

Drew Adams <[hidden email]> writes:

> That would also mean we wouldn't need `lax-plist-*' functions.

Yes, those are horrible functions, and are barely used anywhere.  (And
`lax-plist-member' is missing.)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#47425: [External] : Re: bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST function

Drew Adams
> > Please consider adding a TEST comparer arg for plist keys.
> >
> > In Elisp, a plist key need not be a symbol:
> >
> > (plist-put (list "aaa" 1 "bbb" 2 "ccc" 3) "bbb" 42)
> >
> > That "works" (and no error), but it doesn't do what's expected, since
> > the keys should be compared with `equal' or `string=', not `eq'.
>
> plist-put doesn't ensure that the operation makes sense here, no, but we
> can't really add that at this point, either.

Please elaborate.  I don't know what you're saying,
or why.

> I think adding a comparison function makes sense, but on the other
> hand -- we seem to be moving towards using map.el more for these things
> now, so I'm not sure there's much enthusiasm for that.  On the other
> hand, the generic map functions have the problem that they...  can't
> really be used like plist-put.

No.  Please do _not_ bring generic mapping into this.
This is a legitimate issue about plists and plist
functions.

> So does anybody have an opinion here?  I think I'm in favour of adding a
> comparison function for all three `plist-*' functions.

+1.

> > That would also mean we wouldn't need `lax-plist-*' functions.
>
> Yes, those are horrible functions, and are barely used anywhere.  (And
> `lax-plist-member' is missing.)

Agreed.  But their existence is an argument that the
intention was to provide for the use of `equal' as
an alternative test pred to `eq'.



Reply | Threaded
Open this post in threaded view
|

bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST function

Philipp Stephani
In reply to this post by Lars Ingebrigtsen

> So does anybody have an opinion here?  I think I'm in favour of adding a
> comparison function for all three `plist-*' functions.

I'm not a fan of this since it would mean that these functions will no longer be side-effect-free.
Adding a function argument to a function means that the function can no longer really promise anything, so it leads to code that's harder to reason about.


Reply | Threaded
Open this post in threaded view
|

bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST function

Lars Ingebrigtsen
Philipp <[hidden email]> writes:

> I'm not a fan of this since it would mean that these functions will no
> longer be side-effect-free.  Adding a function argument to a function
> means that the function can no longer really promise anything, so it
> leads to code that's harder to reason about.

`plist-put' already mutates state (of the plist), so it's not
side-effect-free...

The other ones are, though.  But...  I'm not sure that's really much of
a concern in practice.  (And Emacs should be able to reason about the
function, still, if the predicate passed in is side effect free, but I
guess we don't have the machinery for that in place?)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no