Re: fadr

From:

Dmitry Dzhus

Subject:

Re: fadr

Date:

Mon, 22 Jun 2009 23:56:27 +0400

User-agent:

Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (gnu/linux)

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
む