From: ···@orsi.com
Subject: Mutation and the Environment Model of Evaluation
Date:
Message-ID: <863808700.111@dejanews.com>
I had previously posted this, but it somehow got lost. I apologize
for any redundancy.
Consider the following interaction in scheme:
(define j (list 1 2 3))
(define (set-car-to-wow! l)
(set-car! l 'wow) ;; original, huh?
(set-car-to-wow! j)
;; unspecified return value
j
(wow 2 3)
What I can't understand is how the environment model
"transmits" information about j unless some shared
structure is used. Let me illustrate:
After set-car-to-wow! is defined the global environment
has (among other things) j is bound to (1 2 3) and
set-car-to-wow! is bound to
lambda-object: Parameters (l)
Body: (set-car! l 'wow)
What happens when (set-car-to-wow! j) is executed?
A new environment is created, E1, which is a child of
the global environment. E1 contains a binding of
(and this is where I'm uncertain) l to (1 2 3).
The body of the procedure is executed, with (1 2 3)
in place of l. But (set-car! (1 2 3) 'wow) is difficult
to interpret. So how does scheme "find" j when it
is no longer apparent from the body of the procedure
to evaluate?
What am I missing? (besdies a life, etc.)
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
> Consider the following interaction in scheme:
>
> (define j (list 1 2 3))
>
> (define (set-car-to-wow! l)
> (set-car! l 'wow) ;; original, huh?
>
> (set-car-to-wow! j)
> ;; unspecified return value
>
> j
> (wow 2 3)
>
...
> The body of the procedure is executed, with (1 2 3)
> in place of l. But (set-car! (1 2 3) 'wow) is difficult
> to interpret. So how does scheme "find" j when it
> is no longer apparent from the body of the procedure
> to evaluate?
>
> What am I missing? (besdies a life, etc.)
I'm not sure where the quesition is, but this might help.
The intermediate computation is equivalent to
(set-car! (list 1 2 3) 'wow)
what you said has an illegal attempt to call the number
1 as a procedure. It is not j that is being changed,
but the start of the list itself.
--
--Keith
This mail message sent by GNU emacs and Linux.
Power to the people. Linux is here.
Food, Shelter, Source code.
···@orsi.com writes:
> (define j (list 1 2 3))
>
> (define (set-car-to-wow! l)
> (set-car! l 'wow) ;; original, huh?
>
> (set-car-to-wow! j)
> ;; unspecified return value
>
> j
> (wow 2 3)
[...]
> What happens when (set-car-to-wow! j) is executed?
> A new environment is created, E1, which is a child of
> the global environment. E1 contains a binding of
> (and this is where I'm uncertain) l to (1 2 3).
It goes like this:
A new environment (E1) is created with l bound to j,
(rather than to (1 2 3)). _After_ the new environment is created,
the body of set-to-wow! is evaluated, and it is only then that
j is looked up in E1 to yield (1 2 3). Then the environment
containing j (global) can be altered to rebind j.
Lyn
> ···@orsi.com writes:
>
> > (define j (list 1 2 3))
> >
> > (define (set-car-to-wow! l)
> > (set-car! l 'wow) ;; original, huh?
> >
> > (set-car-to-wow! j)
> > ;; unspecified return value
> >
> > j
> > (wow 2 3)
> [...]
>
> > What happens when (set-car-to-wow! j) is executed?
> > A new environment is created, E1, which is a child of
> > the global environment. E1 contains a binding of
> > (and this is where I'm uncertain) l to (1 2 3).
>
> It goes like this:
> A new environment (E1) is created with l bound to j,
> (rather than to (1 2 3)). _After_ the new environment is created,
> the body of set-to-wow! is evaluated, and it is only then that
> j is looked up in E1 to yield (1 2 3). Then the environment
> containing j (global) can be altered to rebind j.
>
Sorry, but that's wrong. J is bound to a storage location that
contains (a pointer to) the pair that starts the list. In a new
environment, L is bound to a different storage location that contains
(a pointer to) the same pair. The car of the pair is changed.
Neither the binding of J (or of L) nor the contents of the location to
which they are bound changes. J is not mentioned in the text
of the procedure, and (therefore) has nothing to do with the
evaluation of the procedure.
--
--Keith
This mail message sent by GNU emacs and Linux.
Power to the people. Linux is here.
Food, Shelter, Source code.
From: JosuKa Diaz Labrador
Subject: Re: Mutation and the Environment Model of Evaluation
Date:
Message-ID: <339292e0.3337627@news>
···@orsi.com wrote:
>Consider the following interaction in scheme:
>(define j (list 1 2 3))
>(define (set-car-to-wow! l)
> (set-car! l 'wow) ;; original, huh?
>(set-car-to-wow! j)
>;; unspecified return value
>j
>(wow 2 3)
You raised one of the less explained features, in my opinion, of
Scheme, and some other languages, too. My first language was Pascal,
so when some years ago I read in R4RS that "Arguments to Scheme
procedures are always passed by value", I got your problem too.
I'm going to speak in low level terms (possibly not 100% adequate);
names (like "x") are bound to locations (addresses, l-values), which
have values (r-values). If you have (foo x):
1. if x is a "basic" object (number, char, ...) then a copy of (the
value of) x is passed to the procedure foo.
2. but when x is a "composite" object (string, vector, list, ...)
actually a copy of the address of x is passed as argument to foo.
R4RS defines that pass-by-value "means that the actual argument
expressions are evaluated before the procedure gains control". I
personally think that things have a name:
1. this is pass-by-value,
2. I call this pass-by-reference, as in Pascal, obviously.
Nonetheless, I do not think R4RS having some kind of inconsistence;
you may read that "Variables and objects such as pairs, vectors, and
strings denote locations or sequences of locations":
1. when x is a number, x denotes such number, so in (foo x) the number
itself [not x], is passed;
2. when x is a list, x denotes the location of the list, so in (foo x)
this location is passed.
So, Scheme behaves much as C in this respect, and not as Pascal. You
may have a look to the chapter 6 of Friedman, Wand and Haynes
"Essentials of Programming Languages" (MIT Press, 1992), where all
this stuff is explained admirably.
But clarifying these things with respect to some other languages is
needed in R4RS, in my opinion.
--JosuKa
---------------------------------------------------------------------
JosuKa Diaz Labrador ······@inf.deusto.es ······@acm.org
ESIDE - Universidad de Deusto http://www.deusto.es/~josuka
Apartado 1, 48080 BILBAO (SPAIN) Tel. 34.4.4139000 Fax. 34.4.4139101