Re: fadr

[Dmitry Dzhus]

Thanks for seeing my code.

Chong Yidong wrote:

>  * It's completely unclear what "fadr" stands for. If we keep this
>  file, we must rename it to something less cryptic.

Fast adressing.

>  * More fundamentally, I think the way this library works is misguided.
>    The example given in the commentary says:
>
>      (setq basket '((apples . (((color . green) (taste . delicious))
>                            ((color . red) (taste . disgusting))))))
>
>      Its contents may be accessed using `fadr-member':
>      (fadr-member basket ".apples[1].color")
>      red
>
>    If I understand correctly, this smacks of trying to shoehorn C
>    structure-addressing habits into Emacs Lisp.  Passing a "black-box"
>    string argument like ".apples[1].color" is ugly and un-Lispy.

It seemed to me to be not lispy enough from the very beginning, but I
couldn't think of a better replacement, with «better» meaning «allowing
to write compact yet expressive code». The problem with fadr is that
it's deliberately untyped.

> Unless there is some overriding reason, I think the GDB-MI project
> should drop the fadr dependency.  If you need a way to interface easily
> with nested structures, I suggest using Common Lisp structures, i.e. the
> `defstruct' macro which has been in cl-macs.el for a long time.

I didn't know about this, thanks for pointing out at this facility. I'm
familiar with similar kind of structures from some experience I had with
Scheme. I'll see how I can fit this in my code to work with GDB/MI
responses.

I should use `(eval-when-compile (require 'cl))`, right?
-- 
Happy Hacking.

http://sphinx.net.ru
む