Re: [PATCH] Implement fast verisons of json-parse functions

[Eli Zaretskii]

> From: Herman, Géza <geza.herman@gmail.com>
> Cc: Géza Herman <geza.herman@gmail.com>,
>  emacs-devel@gnu.org
> Date: Sat, 30 Mar 2024 11:50:19 +0100
> 
> 
> >   . 3 tests in test/src/json-tests.el are now failing, where 
> >   they
> >     succeeded before; see the log at the end
> >   . the times of the relevant tests don't seem to be faster than
> >     the libjansson version, perhaps because this is an 
> >     unoptimized
> >     build
> 
> 3 test failures:
> 1. Handling of utf-8 decode errors: the new parser emits 
> json-utf8-decode-error instead of json-parse-error (this is what 
> the test expects).  I can fix this by modifying the test

OK, but we will need to mention this in NEWS as an incompatible
change.

> 2. Handling of a single \0 byte: the new parser emits 
> json-end-of-file.  I think this is not the best error kind for 
> this case, so I'll modify the parser to emit json-parse-error 
> instead.  This is still different what the test expects 
> (wrong-type-argument), but I think there is no reason to treat 
> zero bytes specially.  Considering the JSON spec, it's the same 
> error as any other unexpected byte value.

Does JSON allow null bytes in its strings?  If not, why
wrong-type-argument is not TRT?

> 3. Handling objects with duplicate keys.  That's an interesting 
> one.  With alist/plist objects, the old parser removed duplicate 
> members, but the new parser doesn't remove such members, it keeps 
> them all. The JSON spec doesn't really say anything about this 
> case, so I think we're free to do anything we like. Mattias 
> Engdegård had an interesting idea: what if we put alist/plist 
> members in reversed order? This way, if one uses assq/plist-get to 
> get values by keys, the behavior will be consistent with the hash 
> table representation (which keeps that last value of duplicate 
> keys).  I like the idea of consistency, but I don't like that the 
> elements will become reversed after parsing.  I had the idea that 
> if the hash table kept the first value of duplicate keys, then 
> we'd also have consistency.  What do you think?

I think we should modify the expected results of the test to match the
new behavior, and leave the order as it is now.

But please also compare with what the Lisp implementation does in
these cases, as that could give us further ideas or make us
reconsider.

Mattias, any comments or suggestions?