Re: possible json.el optimization: json-alist-p and json-plist-p recursion

[Stefan Monnier]

> I ran into a very deep recursion with `json-encode' because
> `json-alist-p' is unnecessarily recursive.  This is not a bug, just
> something that can be optimized because (it seems) Emacs Lisp doesn't do
> good tail recursion optimization in this case.

Emacs Lisp doesn't do any tail recursion optimization (to some extent
because it's pretty difficult to do with a dynamically scoped languages,
so hopefully we'll be able to change this for the lexically scoped
dialect) and its function calls are expensive, so it does not handle
recursion very well, indeed (yes, this is sad).

> #+begin_src lisp
> (defun json-alist-p (list)
>   "Non-null if and only if LIST is an alist."
>   (or (null list)
>       (and (consp (car list))
>            (json-alist-p (cdr list)))))
> #+end_src

> I wanted to ask if this was an OK replacement:

> #+begin_src lisp
> (defun gnus-sync-json-alist-p (list)
>   "Non-null if and only if LIST is an alist."
>   (let ((p list))
>     (while (consp p)
>       (setq p (if (consp (car-safe p))
>                   (cdr p)
>                 'not-alist)))
>     (null p)))
> #+end_src

I guess it's OK tho "car-safe" seems unneeded since you've just tested
consp before (note that the original code didn't even check (consp p)
and just signaled an error if `list' is not a proper list).

Oh, and you don't need to copy `list' into `p', you can work on `list' directly.

>     (while (consp p)
>       (setq p (if (and (keywordp (car-safe list))
>                        (consp (cdr-safe p)))

Same here about car-safe and cdr-safe, and additionally, I think you
don't want to test `list' but `p' instead (tho here again, you probably
want to work on `list' directly without using a `p').


        Stefan