[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 22 Jun 2009 20:27:44 +0400
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.
> * 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.color")
> 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.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?
- fadr, Chong Yidong, 2009/06/22
- Re: fadr, Thien-Thi Nguyen, 2009/06/22
- Re: fadr,
Dmitry Dzhus <=
- Re: fadr, Dmitry Dzhus, 2009/06/22
- fadr, Nick Roberts, 2009/06/23