Re: Realtime cost of call by value

[taltman]

Hi John,

In Scheme, lists & vectors are passed as references to those data
structures. "set!" mutates the current environment's binding of
identifiers to values. "vector-set!" mutates the pointers of the
elements of the given vector ( Scheme's array data type). Since it
doesn't operate on identifiers, there's no oddity.

There's no copy. When Scheme sees that you are about to bind a
variable to a value, it updates the local scope. Of course, Scheme is
going to attempt to evaluate the value before binding the variable (
Scheme doesn't follow a "lazy" evaluation approach, like Haskell ). If
there's no reference to the identifier of the parent scope, in the
course of the evaluation, then Scheme never touches the parent scope's
use of that variable. But, if you do something like this:

guile> (let   ( ( a 5         ) )
         (let ( ( a ( + a 5 ) ) )
                 a            ) )
10
guile>

Then the second binding of "a" forces Scheme to attempt to evaluate
"a", so it starts to back-track up the lexical scope ( in this case,
it hits the previous binding of a ).

In the first example you gave, a Scheme interpreter would have passed
a reference to s1 ( a "pointer", if it were implemented in C, for
example ), and a NEW binding would be formed, where the lambda
function's argument-variable of "s" would be bound to the same value of
"s1". "s" never 'became' "s1", so to speak.

In the second example, the same follows. "v" was bound to the value of
"v1", which is a pointer to a vector data type. So when "vector-set!"
performed a mutation on the elements, it first dereferenced the
pointer to the vector. So the same memory was accessed. 

It is very clear where this would be useful in Octave: in how arrays,
cell arrays, and the soon-to-be-deprecated list types are handled in
function calls. This would allow for the same kind of performance
benefits that Glenn was able to obtain. I guess this can be achieved
via the "global" variable type, but it just seems that this behavior
should be exhibited for these three data types by default.

Cheers,

~Tomer




On Oct 31, 2003 at 12:33pm, John W. Eaton wrote:

jwe >Date: Fri, 31 Oct 2003 12:33:25 -0600
jwe >From: John W. Eaton <address@hidden>
jwe >To: address@hidden
jwe >Cc: address@hidden
jwe >Subject: Re: Realtime cost of call by value
jwe >
jwe >On 31-Oct-2003, address@hidden <address@hidden> wrote:
jwe >
jwe >| Just FYI, many high-level languages ( I'll use Scheme as an example )
jwe >| don't EVER pass variables to functions via call-by-value, but
jwe >| call-by-reference. I'm talking about the interpreter, *not* the actual
jwe >| language. What this means, is that for any level of nested function
jwe >| calls, and for any number of arguments, there isn't a heavy
jwe >| performance penalty for large arguments. So even though it might look
jwe >| like you're just flat-out passing off a huge variable, internally only
jwe >| the scoped reference to that variable is being manipulated.
jwe >
jwe >?
jwe >
jwe >This is somewhat off topic, but...
jwe >
jwe >If I do something like
jwe >
jwe >  (define foo (lambda (s) (set! s -9999) s))
jwe >  (define s1 1)
jwe >  (foo s1)
jwe >  s1
jwe >
jwe >only the local variable a will be changed (at least .  The top-level 
variable b
jwe >will not change.  So somewhere, a copy is made (or a new definition is
jwe >given to a variable), even if the argument is passed by reference.
jwe >
jwe >OTOH, if I write
jwe >
jwe >  (define foo (lambda (v) (vector-set! v 1 -9999) v))
jwe >  (define v1 #(1 2 3))
jwe >  (foo v1)
jwe >  v1
jwe >
jwe >then you will see that the local variable v and the top-level variable
jwe >v1 both change.  (This is like the mutable and non-mutable objects
jwe >that Python has as well.)
jwe >
jwe >This is NOT the way that Octave is defined to function, because that
jwe >is not the way the Matlab works.  So, this might be great in some
jwe >respects, but there is no way we can change this behavior in Octave.
jwe >
jwe >Also, it seems somewhat bad to me that you have to keep track of which
jwe >kinds of objects have this special mutable property.  I suppose people
jwe >get used to it, but if you are familiar with Octave/Matlab
jwe >programming, it would seem to me that it could cause some trouble.
jwe >
jwe >| What this kinda requires of the language, though, is some sort of
jwe >| formal bookkeeping of variable scope.
jwe >
jwe >?
jwe >
jwe >I think that is kinda required by just about any language.
jwe >
jwe >| It isn't that hard to implement a lexical scope. I'd recommend "The
jwe >| Structure and Interpretation of Computer Programs" for a good, clean
jwe >| explanation of how to achieve just this:
jwe >| 
jwe >| http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-26.html
jwe >
jwe >That's fine, but how is it going to help Octave?
jwe >
jwe >jwe
jwe >



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------