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 <drew.adams@oracle.com>]

> >  (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).