Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!darwin.sura.net!howland.reston.ans.net!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: call by value, again
Message-ID: <hbakerCz9z4D.4M4@netcom.com>
Organization: nil
References: <3a5eff$k52@agate.berkeley.edu> <BLUME.94Nov13133704@dynamic.cs.princeton.edu> <3a8ft3$smn@agate.berkeley.edu>
Date: Mon, 14 Nov 1994 20:48:11 GMT
Lines: 86

In article <3a8ft3$smn@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>blume@dynamic.cs.princeton.edu (Matthias Blume) writes:
>>[I'm sitting here in tears...]
>
>Well, here's another one...
>
>    From: Axel Wienberg <2wienbe@informatik.uni-hamburg.de>
>    To: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
>
>      I happened to read your article on comp.lang.scheme the day after I
>    have read "OOPS MESSENGER volume 4 number 4 october 1993". OOPS
>    MESSENGER is "a quarterly publication of the special interest group on
>    programming languages (SIGPLAN)" of the ACM.
>      This OOPS MESSENGER contains an interesting article by Henry
>    G. Baker (he's an occasional visitor of comp.lang.scheme, too). And
>    this article contains an interesting section titled "call-by-reference
>    versus call-by-value" ! He argues for a third way of argument passing
>    called "call-by-object-reference". Quoting:
>
>      Lisp is sometimes characterized as "call-by-value", but this is
>      incorrect. Lisp approximates call-by-object-reference semantics
>      extremely well, and the single lacuna can be easily repaired. The
>      reason Lisp appears to be call-by-value is that arguments which are
>      functional [i.e. immutable] data structures appear to have been
>      passed in toto. However, it is the nature of functional data
>      structures that whether they are passed by value or by reference is
>      not determinable, hence we consider these data structures to have
>      been passed by "object-reference".
>
>      "Call-by-value" coerces arguments into their "values", which causes
>      mutable portions of a structure to be replaced by their current
>      value; Lisp does not usually do this. The single exception is caused
>      by variables, which are made variable by SETQ. If we make variable
>      bindings permanent, then we can eliminate this exception. [...]  SETQ
>      of local variables can be eliminated through "cell introduction" for
>      mutable local variables, discussed in several sections above. After
>      these changes, the binding of all lambda variables is constant
>      (although they are sometimes bound to mutable cells), and argument-
>      passing becomes completely uniform. Of course, when cells are
>      introduced for mutable lambda variables, any variable instances -
>      including those in argument lists - are replaced by expressions
>      which access the cell's value, thus making any coercion explicit.
>
>    I can't tell if this is intelligable without the context. If in doubt,
>    take a look at hbaker's original article.  Feel free to forward this mail
>    to comp.lang.scheme if you deem it appropriate.
>
>    --axe	(2wienbe@rzdspc2.informatik.uni-hamburg.de)
>    "If I have not seen as far as others, then that's |  Axel Wienberg
>     because giants were standing on my shoulders"    |  Hinzeweg 9
>			    Hal Abelson		  |  21075 Hamburg
>
>Perhaps Henry Baker would like to comment on this?

I thought that the above paragraphs explained it pretty well, already. ;-)

One problem with this excerpt is that the definition of object
identity is not present, so that what an 'object reference' is isn't
defined.  IMHO this gets into the issues of 'equality', which is the
whole point of the above-referenced paper (which is called 'Equal Rights
for Functional Objects', and is available in my ftp directory).

Will Clinger's comment (in another posting) on 'applicative order' and
'call by value' is correct, as far as it goes.  However, the theorem
he mentions refers to 'pure' Scheme without side-effects.  My 'Equal
Rights' paper attempts to extend these notions to languages _with_
side-effects (i.e., assignment).

One thing that I would add is that Algol-68, Bliss and ML do
essentially the right thing, because they make 'cells' (unfortunately
misnamed 'references' in Algol-68 and ML, I think) explicit.

The other thing that should be pointed out is that if an object has
only one path to it in the entire system -- i.e., it is 'unaliased' --
then call-by-name and call-by-value again coincide.  A style of
programming called 'linear' makes essential use of this fact to
perform 'in-place' updates completely functionally, and without any
compiler hair.  This is the subject of some other papers in my ftp
directory.

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
      Contact hoodr@netcom.com if you have trouble ftping



