bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Drew Adams]

 (plist-put (list 'a 'b 'c) "a" 42)

Debugger entered--Lisp error: (wrong-type-argument plistp (a b c))
  plist-put((a b c) "abc" 42)
  eval((plist-put (list (quote a) (quote b) (quote c)) "abc" 42))

That's all fine and dandy, except that there is no predicate `plistp'.

See (elisp) Type Predicates:

  All built-in functions do check the types of their actual arguments
  when appropriate, and signal a 'wrong-type-argument' error if an
  argument is of the wrong type.

It makes no sense to refer to `plistp' in the error message if it
doesn't exist.  If it won't exist then the error message should say that
the arg isn't a plist - not mention `plistp'.  Even just saying "plist"
in the error message would be an improvement in this regard.  But the
right fix is to define a `plistp' primitive.

Not only that, but the error is _not_, apparently that the first
arg isn't a proper plist.  For example, this raises no error:

 (plist-put (list 'a 'b 'c) "a" 42)

And it returns the list (a 42 c).  Clearly the error was raised
not because of an improper plist but because the key to look up
is a string and the keys in the almost-plist are symbols.

In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.19041
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Lars Ingebrigtsen]

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

>  (plist-put (list 'a 'b 'c) "a" 42)
>
> Debugger entered--Lisp error: (wrong-type-argument plistp (a b c))
>   plist-put((a b c) "abc" 42)
>   eval((plist-put (list (quote a) (quote b) (quote c)) "abc" 42))
>
> That's all fine and dandy, except that there is no predicate `plistp'.

The backtrace there doesn't seem to be a result of the example form,
but, yes, the error here isn't very good.  Adding a `plistp' predicate
would perhaps make sense, but it would just be

(and (listp list)
     (zerop (mod (length list) 2)))

and then we have the philosophical issue of "is nil a plist"?  Does
anybody have any opinions?

> Not only that, but the error is _not_, apparently that the first
> arg isn't a proper plist.  For example, this raises no error:
>
>  (plist-put (list 'a 'b 'c) "a" 42)
>
> And it returns the list (a 42 c).  Clearly the error was raised
> not because of an improper plist but because the key to look up
> is a string and the keys in the almost-plist are symbols.

Here you probably meant to say:

(plist-put (list 'a 'b 'c) 'a 42)

And that does indeed not result in any errors, but it's not because of
the stringiness of anything, but because 'a exists in the list, and
plist-put doesn't check whether the list is a plist in that case.  Only
when adding new elements does it check:

(plist-put (list 'a 'b 'c) 'd 42)

This signals an error.

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

bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Drew Adams]

> >  (plist-put (list 'a 'b 'c) "a" 42)
> >
> > Debugger entered--Lisp error: (wrong-type-argument plistp (a b c))
> >   plist-put((a b c) "abc" 42)
> >   eval((plist-put (list (quote a) (quote b) (quote c)) "abc" 42))
> >
> > That's all fine and dandy, except that there is no predicate `plistp'.
> 
> The backtrace there doesn't seem to be a result of the example form,

What do you mean by that?

> but, yes, the error here isn't very good.

That's perhaps the main point, in spite of the Subject
line.  Whether there should be a `plistp' predicate is
separate from whether and what error should be reported
here.  Feel free to change the Subject line to something
more general, or to split this into two or more bugs:
(1) bad error report, (2) how to handle `plist-put'
etc., including whether to tolerate improper plists,
(3) whether to add a `plistp' primitive.

> Adding a `plistp' predicate would perhaps make sense,
> but it would just be
> 
> (and (listp list) (zerop (mod (length list) 2)))

Maybe, but maybe, like other such preds, it should
be done in C.

> and then we have the philosophical issue of "is nil a plist"?  Does
> anybody have any opinions?

Yes, of course it's a plist, IMO.  Why wouldn't it be?

On the other hand, a probably more important question
is the cost of getting the length of the list.  That
would be my main hesitation to say we should really
have a `plistp' predicate.

Errors like the one above should be handled correctly.
The error is NOT that the list is not a plist.

And I could argue that we should take the same approach
we take to things that apply to lists, e.g. to elements
of a list.  We generally do NOT require list operations
to be passed a proper list - typically a list whose last
cdr is an atom can still be handled by most operations.

I think the same should probably be true for plists.
If the particular operation doesn't need to traverse the
entire list then it shouldn't - no test for a proper
plist.

Let other kinds of errors be raised as appropriate.
Errors like the one reported here are NOT about the plist
not being proper (in this case not an even # of elements).
They are about a particular plist element or a particular
value that's tested against the plist.

> > Not only that, but the error is _not_, apparently that the first
> > arg isn't a proper plist.  For example, this raises no error:
> >
> >  (plist-put (list 'a 'b 'c) "a" 42)
> >
> > And it returns the list (a 42 c).  Clearly the error was raised
> > not because of an improper plist but because the key to look up
> > is a string and the keys in the almost-plist are symbols.
> 
> Here you probably meant to say:
> (plist-put (list 'a 'b 'c) 'a 42)

Yes.

> And that does indeed not result in any errors, but it's not because of
> the stringiness of anything, but because 'a exists in the list, and
> plist-put doesn't check whether the list is a plist in that case.

Precisely.  That's what I wrote immediately above.
Let plists be handled the way lists are handled: if
a particular operation doesn't need the plist to be
proper then don't check for it to be proper.  If an
operation does need a proper plist then that operation
will, itself, find out whether it can be effected,
and raise an error if not.

> Only when adding new elements does it check:
> 
> (plist-put (list 'a 'b 'c) 'd 42)
> This signals an error.

Even that wouldn't need to raise an error, if `put'
added entries at the beginning instead of the end.

The manual says:

  It may modify PLIST destructively, or it may
  construct a new list structure without altering the old.  The
  function returns the modified property list, so you can store that
  back in the place where you got PLIST

Even to replace an existing entry there's no need in
general, to traverse the entire list.  IOW, I think
`put' could be smarter: Look for an existing entry,
which would mean traversing the list if there is none,
but that traversal could be tolerant and not care
whether the plist is proper.  And if no existing
entry is found it could add the new entry at the
beginning of the plist (or at the end of its proper
portion, just before the atomic last cdr). 

bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Lars Ingebrigtsen]

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

>> >  (plist-put (list 'a 'b 'c) "a" 42)
>> >
>> > Debugger entered--Lisp error: (wrong-type-argument plistp (a b c))
>> >   plist-put((a b c) "abc" 42)
>> >   eval((plist-put (list (quote a) (quote b) (quote c)) "abc" 42))
>> >
>> > That's all fine and dandy, except that there is no predicate `plistp'.
>> 
>> The backtrace there doesn't seem to be a result of the example form,
>
> What do you mean by that?

The backtrace has "abc"; the code example does not.

> On the other hand, a probably more important question
> is the cost of getting the length of the list.  That
> would be my main hesitation to say we should really
> have a `plistp' predicate.

Why?  It's not like we'd use it for anything much.  

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

bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Drew Adams]

> The backtrace has "abc"; the code example does not.

Yeah, sorry; typo.

> > On the other hand, a probably more important question
> > is the cost of getting the length of the list.  That
> > would be my main hesitation to say we should really
> > have a `plistp' predicate.
> 
> Why?  It's not like we'd use it for anything much.

I meant that if we really had an (accurate) error msg
saying that the plist wasn't proper then in order to
test that for each `plist-put' or whatever we'd have
to traverse every plist argument, to see if it really
is proper.

To test that `(a b c)' isn't a proper plist we'd need
to check that the number of elements is even.

We could of course have a `plistp' predicate without
using it to test during `plist-put' etc.

bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Lars Ingebrigtsen]

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

> I meant that if we really had an (accurate) error msg
> saying that the plist wasn't proper then in order to
> test that for each `plist-put' or whatever we'd have
> to traverse every plist argument, to see if it really
> is proper.
>
> To test that `(a b c)' isn't a proper plist we'd need
> to check that the number of elements is even.

We are not going to check that, because it wouldn't be
backwards-compatible.

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

bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Drew Adams]

> > I meant that if we really had an (accurate) error msg
> > saying that the plist wasn't proper then in order to
> > test that for each `plist-put' or whatever we'd have
> > to traverse every plist argument, to see if it really
> > is proper.
> >
> > To test that `(a b c)' isn't a proper plist we'd need
> > to check that the number of elements is even.
> 
> We are not going to check that, because it wouldn't be
> backwards-compatible.

Good.

If we don't use `plistp' in such cases then it's fine to
add it.  And it's not important to do so.

Then see my previous msg about the real problems.
This bug really shouldn't be about adding a `plistp'
predicate, as I indicated.  It all depends on how you
intend to deal with the real problems.

bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Adding a `plistp' predicate
> would perhaps make sense, but it would just be
>
> (and (listp list)
>      (zerop (mod (length list) 2)))
>
> and then we have the philosophical issue of "is nil a plist"?  Does
> anybody have any opinions?

I decided that nil satisfies plistp, and I've now pushed a variant of
this to Emacs 29.

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