Hi! I think that the relevant section 3.4 of R5RS might be relevant:
3.4 Storage model
Variables and objects such as pairs, vectors, and strings implicitly
denote locations or sequences of locations. [snip]
An object fetched from a location, by a variable reference or by a
procedure such as car, vector-ref, or string-ref, is equivalent in the
sense of eqv? (section 6.1) to the object last stored in the location
before the fetch.
[snip]
In many systems it is desirable for constants (i.e. the values of
literal expressions) to reside in read-only-memory. To express this, it
is convenient to imagine that every object that denotes locations is
associated with a flag telling whether that object is mutable or
immutable. In such systems literal constants and the strings returned
by symbol->string are immutable objects, while all objects created by
the other procedures listed in this report are mutable. It is an error
to attempt to store a new value into a location that is denoted by an
immutable object.
... and then from 6.1,
6.1 Equivalence predicates
A predicate is a procedure that always returns a boolean value (#t or
#f). An equivalence predicate is the computational analogue of a
mathematical equivalence relation (it is symmetric, reflexive, and
transitive). Of the equivalence predicates described in this section,
eq? is the finest or most discriminating, and equal? is the coarsest.
Eqv? is slightly less discriminating than eq?.
procedure: (eqv? obj1 obj2)
The eqv? procedure defines a useful equivalence relation on objects.
Briefly, it returns #t if obj1 and obj2 should normally be regarded as
the same object. This relation is left slightly open to interpretation,
but the following partial specification of eqv? holds for all
implementations of Scheme.
The eqv? procedure returns #t if:
[snip]
* obj1 and obj2 are pairs, vectors, or strings that denote the same
locations in the store (section 3.4).
I think what this means for you is that in your first example, setting
the car of the car of b affects a because you are changing the value at
the underlying location "in the store." The object you got by using car
denotes the same location in the store, according to 3.4.
In the second example, however, you are changing the value of a
variable that holds a constant. When you created a pair using that
variable, you assigned to the field that specific value, instead of an
object denoting a location, as you did in the first example. Therefore
there is no change in the value of a or b.
In short, I think that what the specification is saying is that
"objects such as pairs, vectors, and strings" are essentially
references to locations at which what we would consider their value to
be stored.
Hope that helps! I have been trying to understand it myself.
Regards,
--
Jonathan Chan
j...@fastmail.fm
On Thu, Feb 27, 2014, at 09:28 PM, Andy C wrote:
Hi,
I am trying to wrap my head around following, from [1]SICP book:
#;1> (define a (cons 1 2))
#;2> (define b (cons a a))
#;3> a
(1 . 2)
#;4> b
((1 . 2) 1 . 2)
#;5> (set-car! (car b) 3)
#;6> a
(3 . 2)
... changing underlying value affects everything. However in seemingly
similar exercise:
#;1> (define x 1)
#;2> (define a (cons x x))
#;3> (define b (cons a a))
#;4> a
(1 . 1)
#;5> b
((1 . 1) 1 . 1)
#;6> (set! x 3)
#;7> a
(1 . 1)
#;8> b
((1 . 1) 1 . 1)
nothing really happens. It poses the question, at what point Scheme
uses references instead of evaluating the result. Any ideas?
Thx,
Andy
_______________________________________________
Chicken-users mailing list
[2]Chicken-users@nongnu.org
[3]https://lists.nongnu.org/mailman/listinfo/chicken-users
References
1. http://mitpress.mit.edu/sicp/full-text/book/book.html
2. mailto:Chicken-users@nongnu.org
3. https://lists.nongnu.org/mailman/listinfo/chicken-users
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
