On 5/6/07, William Ramsay <address@hidden> wrote:
This is a long example, but it's my actual code that now does exactly
what I want.
Thanks for posting your code. (A Chicken-based text editor would be a
great tool!) Forgive the long response, but it's not clear to me where
I've confused you, so I'd like to cover the same ground a couple of
I think that your example is consistent with what I was talking about
in my last message, though I'm not 100% certain. Your (set-color)
procedure has calls like this:
(set-foreground (car (list-tail cb4 2)) hexcolor)
(vector-set! backup C_KEY1 hexcolor)
The first line updates a gtk widget, the second updates your data
structure, "backup" (which is really your working-copy). Right?
Since you're using vector-set! here, what's really getting changed is
the vector, "backup" --- you're swapping out some value in the vector
at some position, and replacing it with another. Running with the
building analogy, you're scratching a building off your list, and
pencilling in a new one; but you're not modifying any of the
Similarly, given two copies of a vector, e.g.:
(set! a (get-some-vector))
(define b (make-vector (vector-length a)))
(vector-copy! a b)
Calling (vector-set! a ...) will alter the membership of the "a"
vector, but will leave "b"unchanged. Does that make sense?
In your earlier message, you wrote:
The colors are kept in a vector. What I tried was setting a
variable for each color by referencing it's match in the vector.
This failed because changing the variable changed the vector.
I know you didn't post that older code. But when you say "changing the
variable", were you talking about using "set!"? e.g.
;; initally set the variable
(define v1 (vector-ref backup 0))
;; later on, change the variable
(set! v1 something-else)
In this case, the set! will not have changed the vector in any
way. You're just making v1 refer to something else. Agreed?
However, this code would alter the vector -- at least, it would alter
one of its members:
...where (mutate-thing!) is some procedure that acts on the object,
v1, and changes it in some way. Since the object in question is both
the referent of the variable v1, and also a member of the backup
vector, the mutation would be observable from either place. In this
particular case, calling (mutate-thing! (vector-ref backup 0)) would
have done exactly the same thing. Does that make sense?
Please forgive my code it it seems bloated. The first priority in
programming is always to get it to work first.
Agreed. I won't give a critique, since you didn't ask for one, but
here are a couple things you might not be aware of:
(gtk_entry_get_text (car (cdr line2)))
(gtk_entry_get_text (car (cdr line3)))
(gtk_entry_get_text (car (cdr line4)))
(gtk_entry_get_text (car (cdr line5)))
The expression (car (cdr something)) can also be spelled (cadr
something). Or, if you call (use srfi-1) to include the SRFI-1
list-manipulation procedures, you can spell it (second
(car (list-tail cb4 2))
is equivalent to (list-ref cb4 2), or (third cb4) if you use
SRFI-1. The SRFI-1 library defines list accessors from (first) through
(tenth), by the way. If you're not familiar with this SRFI,
is worth a read.