Re: [Chicken-users] set!

[Jonathan Chan]

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

address@hidden

 

 

 

On Thu, Feb 27, 2014, at 09:28 PM, Andy C wrote:

Hi,

 

I am trying to wrap my head around following, from 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

address@hidden

https://lists.nongnu.org/mailman/listinfo/chicken-users