Re: fadr

[Dmitry Dzhus <dima@sphinx.net.ru>]

Thank you for your feedback, now I really want to discuss what I wrote
and what I should have used instead.

Thien-Thi Nguyen wrote:

> I would also suggest looking at bindat.el, which is adept at wire
> to tree to wire (unpacking/packing) operations for (possibly
> nested) fixed-width data types.

I don't need unpacking, but the lisp structure bindat maps packed data
to is the same as one I use in my code — nested lists and a-lists.

Actually,

> If we already have a tree,

I already have a tree. A lot of different trees with different
structure. Like this, for example:

    (setq threads '((threads . (((id . "1")
                      (target-id . "LWP18334")
                      (frame . ((level . "0")
                                (addr . "0x08048b9a")
                                (func . "mult_matrices_mt")
                                (args . (((name . "m1")
                                          (value . "0x804ba30"))
                                         ((name . "m2")
                                          (value . "0x804ba30"))))
                                (file . "test.c")
                                (fullname . "/home/sphinx/projects/gsoc/test.c")
                                (line . "142")))
                      (state . "stopped"))))
         (current-thread-id . "1")))

I'm pleasantly surprised to see that `bindat-get-field` works with such
tree (and others I have) like charm.

> `bindat-get-field' tweaked or extended is preferable to
> `fadr-member' stunted or recast.

Moreover, it looks like I don't even need to tweak anything, as
`bindat-get-field` is exactly what I was meant to write instead of
`fadr-member`. Its docstring mentions the same C-style dotted notation I
had in mind while writing fadr.

The difference between these two is that `bindat-get-field` is of
variable arity and accepts symbols and integers; for `fadr-member` field
selectors need to be concatenated into a string.

    (defun bindat-get-field (struct &rest field)
      (let ((path))
        (dolist (f field)
          (setq path
                (concat path
                        (cond ((integerp f) (format "[%d]" f))
                              ((symbolp f) (format ".%s" f))))))
        (fadr-member struct path)))

(inverse is longer)

So `fadr-member` is just a reinvented wheel at all.
I'm going to drop it.

> Insert Perlis quote re strings, here....

So what really makes «stark» strings non-lispy (apart from having a
font-lock color which differs from that of symbols and parenthesis)?

Sometimes I need to access several different leaves of my tree in the
same line, so I wrote `fadr-expand` which works as follows:

    (fadr-expand "Thread ~.threads[0].id has name ~.threads[0].target-id" threads)
    =>
    "Thread 1 has name LWP18334"

A more realistic example from my code:

    (fadr-format "~.id (~.target-id) ~.state in ~.frame.func " thread)
    =>
    "1 (LWP18334) stopped in mult_matrices_mt "

I coded this function to save some typing. Now I'm in doubts about
whether it follows the spirit of Lisp.
-- 
Happy Hacking.

http://sphinx.net.ru
む