Re: Trouble understanding define (!)

[Marius Vollmer <mvo at zagadka dot ping dot de>]

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.