[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fadr

From: Dmitry Dzhus
Subject: Re: fadr
Date: Mon, 22 Jun 2009 20:27:44 +0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (gnu/linux)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]