Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!udel!princeton!news.princeton.edu!blume
From: blume@dynamic.cs.princeton.edu (Matthias Blume)
Subject: Re: call by value, again
In-Reply-To: bh@anarres.CS.Berkeley.EDU's message of 11 Nov 1994 21:08:56 GMT
Message-ID: <BLUME.94Nov11170247@dynamic.cs.princeton.edu>
Originator: news@hedgehog.Princeton.EDU
Sender: news@Princeton.EDU (USENET News System)
Nntp-Posting-Host: dynamic.cs.princeton.edu
Organization: Princeton University
References: <3a0mh8$prv@agate.berkeley.edu>
Date: Fri, 11 Nov 1994 22:02:47 GMT
Lines: 86

In article <3a0mh8$prv@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:

It least this one talks about *Scheme*.  I guess I'm rapidly turning
into an active Perl+Tcl+Python-hater.  (C++ is already on my list.)
Ah, well...

   Maybe I missed it in all the stuff about Python, but I don't think there's
   been any response to my last message about this call by value question,
   except for one sarcastic and content-free one.

What last message?  Which response?  I hope you don't refer to my
explanation as being either sarcastic, or content-free, or even both!

   What confuses me is that R4RS seems to use the phrase "call by value"
   to mean what SICP calls "applicative order," namely that argument
   expressions are evaluated before the function is called.

They *are* the same.

   The rest of the world, I think, uses "call by value" to mean that arguments
   are copied, rather than pointers copied.

The rest of the world (as far as I am aware of) uses ``call by value''
to mean:

	- applicative order evaluation, *plus*
	- the callee receives the value of the argument as opposed to a
	  location (``pointer''), where the value of the argument is
	  stored

Essentially you can think of ``call by reference'' as being syntactic
sugar for an ``address-of'' operator wrapped around the argument of
every call to the procedure and a ``dereference'' operator applied to
every occurrence of the formal parameter inside the procedure's body.
In this sense ``call-by-reference'' is not terribly interesting
provided your language has first-class locations (aka ``pointers'').

Semantically more interesting is ``call-by-name'' (normal order
evaluation), or the memoizing version thereof (``call-by-need'').  (Of
course, with first-class procedures this also becomes ``just syntactic
sugar'', even though the issues are somewhat more involved.)

   The last message on this subject from Matthias (as I see it) sets out to
   resolve this conflict by saying that the value of a variable *is* the 
   pointer.

No, what I said was:  The value of a call to the procedure CONS is a
pair of locations, which are mapped by the store to the values of the
arguments of that call to CONS.

Variables are a separate issue.  Variables are mapped to locations by
the *environment*.  This mapping is usually referred to as the
``binding'' of the variable.  The bound location is not ``the value''
of that variable -- it ``contains'' the value.

  (Yes, I know, I'm not supposed to say "pointer."  Okay, the
   value of a variable is a "location" which is separately mapped onto
   what the rest of the world calls a value.)

This is not true.  Read what I wrote above!

   This indeed resolves the conflict between the two meanings of "call by
   value."

It doesn't.  There is no conflict, there are no ``two meanings''.

   But the cost is that we can no longer say "the value of x is 3."

Yes, we can.  ``The variable x is bound to location L by the
environment U, which is then mapped to 3 by the store S. Therefore, by
definition, the value of x is 3.  U ("x") = L, S (L) = 3 ==> E("x") = 3.''

   Instead we must say "the value of x is a location that maps onto 3."

x is *bound* to a location, which is mapped onto 3.

   So, am I confused?  If so, could someone please explain non-sarcastically
   what the confusion is?  Thanks.

Was this non-sarcastical enough?

[I still feel like weeping... seriously.]

Regards,
--
-Matthias
