* bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error @ 2021-03-26 22:27 Drew Adams 2021-03-28 12:50 ` Lars Ingebrigtsen 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2021-03-26 22:27 UTC (permalink / raw) To: 47427 (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'' ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-26 22:27 bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error Drew Adams @ 2021-03-28 12:50 ` Lars Ingebrigtsen 2021-03-28 16:39 ` bug#47427: [External] : " Drew Adams 2022-06-27 10:37 ` Lars Ingebrigtsen 0 siblings, 2 replies; 8+ messages in thread From: Lars Ingebrigtsen @ 2021-03-28 12:50 UTC (permalink / raw) To: Drew Adams; +Cc: 47427 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-28 12:50 ` Lars Ingebrigtsen @ 2021-03-28 16:39 ` Drew Adams 2021-03-28 17:15 ` Lars Ingebrigtsen 2022-06-27 10:37 ` Lars Ingebrigtsen 1 sibling, 1 reply; 8+ messages in thread From: Drew Adams @ 2021-03-28 16:39 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 47427@debbugs.gnu.org > > (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). ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-28 16:39 ` bug#47427: [External] : " Drew Adams @ 2021-03-28 17:15 ` Lars Ingebrigtsen 2021-03-28 18:25 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Lars Ingebrigtsen @ 2021-03-28 17:15 UTC (permalink / raw) To: Drew Adams; +Cc: 47427@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-28 17:15 ` Lars Ingebrigtsen @ 2021-03-28 18:25 ` Drew Adams 2021-03-28 18:27 ` Lars Ingebrigtsen 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2021-03-28 18:25 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 47427@debbugs.gnu.org > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-28 18:25 ` Drew Adams @ 2021-03-28 18:27 ` Lars Ingebrigtsen 2021-03-28 18:35 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Lars Ingebrigtsen @ 2021-03-28 18:27 UTC (permalink / raw) To: Drew Adams; +Cc: 47427@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: [External] : Re: bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-28 18:27 ` Lars Ingebrigtsen @ 2021-03-28 18:35 ` Drew Adams 0 siblings, 0 replies; 8+ messages in thread From: Drew Adams @ 2021-03-28 18:35 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 47427@debbugs.gnu.org > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error 2021-03-28 12:50 ` Lars Ingebrigtsen 2021-03-28 16:39 ` bug#47427: [External] : " Drew Adams @ 2022-06-27 10:37 ` Lars Ingebrigtsen 1 sibling, 0 replies; 8+ messages in thread From: Lars Ingebrigtsen @ 2022-06-27 10:37 UTC (permalink / raw) To: Drew Adams; +Cc: 47427 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-06-27 10:37 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-26 22:27 bug#47427: 26.3; 1. Please define a built-in predicate `plistp', 2. wrong type wrong-type-argument error Drew Adams 2021-03-28 12:50 ` Lars Ingebrigtsen 2021-03-28 16:39 ` bug#47427: [External] : " Drew Adams 2021-03-28 17:15 ` Lars Ingebrigtsen 2021-03-28 18:25 ` Drew Adams 2021-03-28 18:27 ` Lars Ingebrigtsen 2021-03-28 18:35 ` Drew Adams 2022-06-27 10:37 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).