CALL-BY-REFERENCE
    An argument passing convention where the address of an argument variable
    is passed to a function or procedure, as opposed to where the value of
    the argument expression is passed. Execution of the function or procedure
    may have side-effects on the actual argument as seen by the caller.

FORTRAN passes arguments by reference.

Here is an example in C++.

void yuck (int& arg) {
  arg = 69;
  }

void foo () {
  int x = 42;
  int y = x;
  yuck (x);  // X is now 69, Y is still 42.
  }

Common Lisp does not work this way.

A quick google shows that the definition above seems to be prevalent.

In call-by-value, an argument is evaluated *before* it is passed to
the caller.  Suppose function foo were defined as follows:

(defun foo (x y)
  (if (zerop x)
      most-positive-fixnum
      y))

In a call-by-value language, I would get an error if I wrote

(foo 0 (/ 1 0))

In a call-by-name language, however, the variable Y in foo would
not be bound to the value of (/ 1 0), but to the expression `(/ 1 0)'.
Since this expression is not used, the division doesn't happen.

Call-by-need is similar, but there is an efficiency hack.  If Y
*were* to be evaluated, the value is cached for future reference.

I've also disliked the usage of the term "tagged pointer" to describe
the words which describe Lisp objects, for the same reason (pointer
implies address, which doesn't exist for an immediate object).  So I
have always described these tagged words as LispVals, and thus by using
a completely made-up word I avoid the preconception of whether a
LispVal is a pointer or a value (it is both and it is none).  And if
one accepts the made-up and unencumbered term LispVal, it becomes
obvious that Lisp is "pass by LispVal".

[I did not invent the term LispVal, either; and I don't know who did.
I first saw it in the C sources for FranzLisp on the Berkeley Software
Distribution; it was a C typedef which was used to describe the union
of all of the possible lisp types, Maclisp style.]

For myself, I am only recalling what I was taught when I took C and C++ and
that was that C was call-by-value (including the pointers) and C++ provided
a "new and cool" pass-by-reference mechanism.  If you passed a struct in C
as opposed to a reference to struct, your callee received a copy and could
not affect the caller's struct.  (Given a pointer, you could, by mechanisms
of indirection get at the memory contents.)  That has been consistent with
what I recall reading and hearing about it since then and is consistent with
the FAQ's from the C/C++ world on the subject.  (This is not supposed to be
an authoritative argument, just one opinion that counters your own with some
anecdotal support for a consensus argument).

In my C++ texts it always used pass-by-value and pass-by-reference in the
same way Kent and others here seem to be using them.

  I think I regret posting that first seed of this idea.  :)
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

In particular, call-by-reference distinguishes itself from
call-by-value in that the callee can modify the location denoted by
the (l)value (i.e., the _location_) denoted by the actual argument.
But that's not the only location that a callee might want to modify,
and if values _contain_ locations (as it is the case in Lisp as well
as all languages that have the concept of a pointer), then the callee
can perform a mutation that is observable by the caller.

  Yes.  Passing pointers is not the same as pass-by-reference.  "Pass by
  reference" means that a reference to the storage of the value is passed,
  but the value in Common Lisp is a pointer or a number/character.  Common
  Lisp does _not_ pass a pointer to the pointer-or-number/character.
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

"Pierre R. Mai" <p...@acm.org> wrote in message news:87lmb2r7ns.fsf@orion.bln.pmsf.de...

(defmacro reference (&environment env place)
  "Construct a reference to PLACE for call-by-reference semantics."
  (multiple-value-bind (dummies vals new setter getter)
      (get-setf-expansion place env)
    (let ((inner-form `(MAKE-REFERENCE
                        :name ',place
                        :getter (LAMBDA () ,getter)
                        :setter (LAMBDA ,new ,setter))))
      (if (and (null dummies) (null vals))
          inner-form
          `(LET* (,@(mapcar #'list dummies vals))
             ,inner-form)))))

So this works properly:

(defun bar (array-ref)
  (incf (dereference array-ref)))

  Look, this is getting annoying.  The reference that is intended in the
  term pass-by-reference is not the value of the variable (storage cell),
  it is the variable (storage cell) itself.  This has been the established
  meaning of these terms basically forever.  You are seriously confused if
  you think pointers as such constitute references.

  There are three very, very common ways to pass arguments to functions:

1 Pass by value: The value of the variable (storage cell) is extracted by
  the caller and passed to the callee.  This also means that all arguments
  to a function are just values and a function call can just evaluate all
  arguments in order and pass the values to the callee.  This is precisely
  what Common Lisp specifies.

2 Pass by reference: The variable (storage cell) is passed to the callee,
  which can read or write to it.  This means that you cannot call a
  function with the value of another function call without storing it in a
  variable.  Fortran has _traditionally_ been pass-by-reference.  Ada has
  out parameters.  C++ has references (coincidence? not!).

3 Pass by name: The expression itself is passed to the callee, which will
  re-evaluate it with the values of subexpressions captured in the call.
  (They actually pass closures much like I and Joe and Pierre offered with
  the setter/reference macro.)  This is what Algol and Simula can do.

  This is (or should have been) CS 101 material.  Please just learn it and
  avoid confusing others who might have no education at all and are likely
  to listen to bogosities.  Having to clean up after such confusions is
  both annoying and wasteful when you could have avoided the "information
  pollution" in the first place.
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

The following C program produces the output below it:
............................................
#include <stdio.h>

struct thing {int x; int y;};

void foo(struct thing arg)
{arg.x = 1;}

int main(int argc, char* argv[])
{
   struct thing bar;
   bar.x = 0;
   bar.y = 0;
   printf("\nbar: x = %d  y = %d", bar.x, bar.y);
   printf("\ncalling foo...");
   foo(bar);
   printf("\nbar: x = %d  y = %d", bar.x, bar.y);
   return 0;

The lisp version does this:

CL-USER 10 > (defstruct thing x y)
THING
CL-USER 11 > (defun foo (arg)
              (setf (thing-x arg) 1))
FOO
CL-USER 12 > (defun main ()
              (let ((bar (make-thing :x 0 :y 0)))
                (format t "~&bar: x = ~A  y = ~A"
                        (thing-x bar) (thing-y bar))
                (print "calling foo...")
                (foo bar)
                (format t "~&bar: x = ~A  y = ~A"
                        (thing-x bar) (thing-y bar))))
MAIN
CL-USER 13 > (main)
bar: x = 0  y = 0
"calling foo..."
bar: x = 1  y = 0
NIL

Anyway, there is clearly something missing in your definitions or in the way
you are applying the labels.

- pass-by-value can have no side-effects
- (eq pass-by-reference (pass-by-value pointer))

Come to think of it, they were the ones that told me those
in the first place. I remember arguing with the prof. over
something he had told the class that was just plain wrong,
and he replied that the concepts being introduced were bad
enough without burying first year students with details not
germane to the day's subject.

So your question above asks the wrong thing.  We are not talking about
"mere collections of values", we are talking about collections of
locations.  In some languages, where certain composite types such as
CONS are always immutable, one can do away with the step of mapping
locations to values via the store and consider the CAR of a CONS part
of the CONS.  On the implementation side you probably still allocate
physical memory for such a CONS (at least in most cases), but you do
not have to mention that in the formal semantic model.  In a semantic
model for Lisp you do have to mention locations in some way or the
other because you need to be able to model mutation.

To go back to you question.  Suppose you give me ("a collection of")
two values x and y.  Now I construct (CONS x y).  You will certainly
agree with me that the result of this expression is more than "just
the two values". In fact, I can prove this to you by calling (CONS x
y) again -- which results in something that is observably different
from the first result.  Thus, the two values in a CONS are not "just a
collection of two values".  Instead, the result of CONS is a
collection of two locations, which initially happen to hold the two
values you gave me.  If you do a RPLACA or RPLACD on the result of
CONS, you still have the same cons cell (i.e., you did NOT change this
value).

So maybe this description could be correct, and informative for
outsiders:

  Common Lisp is call-by-value. Every value is (or can be considered
  to be) a pointer, however some values (like numbers, characters, and
  nil) are immutable.

Or, using Duane Rettig's word:

  Common Lisp is call-by-value. Every value is a LispVal, which is a
  tagged word, which is ...

The "every value is a pointer" bit seems to be crucial piece of
information, otherwise people apparently expect the callee to receive
a copy of for example a cons cell. This is what C does, because there
every value is _not_ a pointer.

http://groups.google.com/groups?selm=gat-1002021217330001%40192.168.1.50

---

I think it's worth pointing out that even though Lisp and C++ are both
call-by-value the actual behavior you get from Lisp's calling convention
more resembles (but is not identical to) what you get from
call-by-reference in C++.  For example, consider:

class C {
public:
  int x;

main() {
  C c;
  c.x=0;
  f(c);
  cout << c.x;

(defclass C () (x))

(defun f (c) (incf (slot-value c 'x)))

(defun main ()
  (let ( (c (make-instance 'C)) )
     (setf (slot-value c 'x) 0)
     (f c)
     (print (slot-value c 'x))))

The output of the C++ version is '0' while the Lisp version output is
'1'.  (On the other hand, if you changed f in the C++ version to be f(C
&c) then it too would output '1'.)  The difference arises because:

The problem here, I think, is in the dual meaning of the term "value".
There seem to be two prevalent meanings to the term "by-value"; one
means "passed after evaluation", and one means "copied".  Both are
attempts to meet the real goal of a procedure not affecting the
variables owned by its caller (even so, C does not meet this goal).
This dual meaning is why I object to the term "by-value" to describe
Lisp calling style.

Lisp objects are what are passed, and the values of variables tend not
to be owned specifically by functions, but are owned as a whole by the
process (I suspect that's mostly true of all gc'd languages).

See my previous answer to you on this thread.

It starts off

   Because variables, pairs, and vectors may hold values of any type,
   Scheme implementations use a uniform representation for values -- a
   single type large enough to hold either a complete value or a
   pointer to a complete value, along with the necessary typing
   information.

   The following sections will present a simple typing system, and
   then make some refinements to correct its major
   weaknesses. However, this is not a description of the system Guile
   actually uses. It is only an illustration of the issues Guile's
   system must address. ...

1.  The C code allocates a struct on the stack, the Lisp code
    allocates it in main memory.  So you'd need to call malloc
    in the C code.

2.  C allows you to pass structs in argument lists.  The way
    this works is that the struct is `destructured' at the call
    site, and `restructured' at the callee.

    Lisp provides this for lists via APPLY and &REST args.

(defstruct (thing (:type list)) x y)

(defun foo (&rest bar)
  (setf (thing-x bar) 1))