Re: New jrpc.el JSONRPC library

[João Távora]

Aaron Ecay <address@hidden> writes:

> Hi João,
>
> 2018ko maiatzak 21an, João Távora-ek idatzi zuen:
>> 
>> Hi Aaron,
>> 
>> Nice, i didn't know about that. Does it have an equivalent to
>> &allow-other-keys and &rest?
>
> &allow-other-keys is always true for the pcase version.
> As I understand what &rest does, it lets you bind certain keys, and
> then bind the map minus those keys to another variable.

No, not "minus those keys", those keys are included in the &rest var
too. 

> Thereʼs nothing like that out of
> the box, but it can easily be implemented:
>
> (pcase-defmacro map-and-rest (rest-var &rest keys)
>   `(and (map ,@keys)
>         (app (map-filter (lambda (key _val) (not (memq key ',keys)))) 
> ,rest-var)))
>
> (pcase-let* (((map-and-rest rest foo bar) '((foo . 1) (bar . 2) (baz . 3))))
>   (list foo bar rest))
> ;; -> (1 2 ((baz . 3)))

Hmm:

1. Not particularly readable for someone  that encounters the second
   form. Can one M-. from map-and-rest into the defmacro to learn what
   it is doing?
2. The absence of control over &allow-other-keys is a big minus. It's
   very useful to a) check that the object isn't providing an unknown
   key, or to check that you haven't mistyped a key name. Can you
   code it into the pcase-defmacro?
3. Also can you code the more complex capabilities of &key into there?

   ;; default values
   (cl-destructuring-bind (&rest rest &key (foo "default") bar) nil
      (list foo bar)) ;; -> ("default" nil)

   ;; provided-p
   (cl-destructuring-bind (&rest rest &key (foo nil foo-provided-p) bar)
          '(:bar nil :foo nil)
      (list foo bar foo-provided-p)) ;; -> (nil nil t)

   ;; alias
   (cl-destructuring-bind (&rest rest &key
          ((:extremely-long-foo-with-the-airplane foo)) bar)
          '(:extremely-long-foo-with-the-airplane 42)
      (list foo bar)) ;; -> (42 nil)

I think clients of jsonrpc.el should be able to use whatever they want
to destructure JSON (though I recommend plists and I think it should be
the default datatype passed to the dispatcher). Internally, in
jsonrpc.el there isn't an awlful lot of destructuring going on, so if
someone can provide a superior argument (performance?) backed up by some
measurements, I don't mind switching. It's just that the readability
argument isn't really holding up against cl lambda lists.

João