This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Trouble understanding define (!)
Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> The problem I have with this is that I have probably already chosen
> the name of the variable representing the <address-book> to indicate
> its contents, e.g., `address-book'. So, the expression
>
> (address-book:n-entries address-book)
>
> will be redundant: both the first and the second element says that
> we're dealing with an address-book.
>
> I want to write
>
> (n-entries address-book)
>
> and
>
> (n-entries phone-list)
Yes, I see. In my view, this is dangerously close to "do what I mean,
not what I said".
I will gladly go with the longer names. I tend to have short,
undescriptive non-top-level names and longer, descriptive top-level
names (expect for functions where I generally tend to use long names).
So, I would probably write your example as
(address-book:n-entries ab)
The code whre I use GOOPS right now is data structure rich and weak in
protocols. I have a macro that turns things like
(define-struct address-book () n-entries)
into
(begin
(export address-book address-book-n-entries address-book?)
(define-class address-book ()
(n-entries #:accessor address-book-n-entries
#:init-keyword #:n-entries))
(define (address-book? x) (is-a? x address-book)))
and then I write address-book-n-entries all over the place. I didn't
like that in the beginning because was so much more verbose than what
I would write in C++. But once the code is written, it is much
cleaner to read, especially when your structures get interconnected in
interesting ways. For example, I have code like this
(format #t " ~a:~a"
(comp-name (assoc-comp (signal-src s)))
(formal-name (assoc-formal (signal-src s))))
I have learned to like the explicitness of this code. If I drop the
prefixes, I have the feeling that I'm not completely in control.