Official definition of call-by-value (Re: Finding the instance reference...)

Terry Reedy tjreedy at
Thu Nov 13 18:54:39 CET 2008

Fredrik Lundh wrote:
> greg wrote:
>> If you're going to indulge in argument by authority,
>> you need to pick authorities that can be considered,
>> er, authoritative in the field concerned...
> Like Barbara Liskov, who's won tons of awards for her work on computer 
> science and programming languages, and who was among the first to 
> design, implement, and formally describe a language with *exactly* the 
> same evaluation semantics as Python?  What did she and her co-authors 
> have to say about the calling semantics in their new language?  Let's see:
>     "In particular it is not call by value because mutations
>     of arguments performed by the called routine will be
>     visible to the caller.  And it is not call by reference
>     because access is not given to the variables of the
>     caller, but merely to certain objects."

CLU reference manual. 1979  Google's searchable HTML version (apparently 
from OCR of scan package as .pdf) with a few mis-conversions.

We call the argument passing technique call by sharing, because the
argument objects are shared between the caller and the called routine.

She later. in 1992, called it "pass by object" (below).

> But maybe they were just ignorant, and didn't really "get" how earlier 
> languages worked?  Let's see what Liskov has to say about that:
>     "The group as a whole was quite knowledgeable about languages that
>     existed at the time. I had used Lisp extensively and had also
>     programmed in Fortran and Algol 60, Steve Zilles and Craig
>     Schaffert had worked on PL/I compilers, and Alan Snyder had done
>     extensive programming in C. In addition, we were familiar with
>     Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
>     languages. Early in the design process we did a study of other
>     languages to see whether we should use one of them as a basis for
>     our work [Aiello, 1974]. We ultimately decided that none would be
>     suitable as a basis. None of them supported data abstraction, and
>     we wanted to see where that idea would lead us without having to
>     worry about how it might interact with pre-existing
>     features. However, we did borrow from existing languages.  Our
>     semantic model is largely borrowed from Lisp; our syntax is
>     Algol-like."
> Still think they didn't understand Algol's semantic model?

The second quote come from
A History of CLU, by Barbara Liskov 1992

Python owes more to CLU than I realized.

"Assignment has a type-independent meaning with the heap approach;
x := e
causes x to refer to the object obtained by evaluating expression e."

"arguments are passed "by object"; the (pointer to the) object resulting
from evaluating the actual argument expression is assigned to the 
formal. (Thus passing a parameter is just doing an assignment to the 

Exactly described Python also.

"we wanted to treat built-in and user-defined types alike"

Achieved fully in 3.0.  She notes a difference though: some built-in 
types have literals.  No user types do.

"We allow common operator symbols but these are only short forms for 
what is really happening, namely a call on an operation using its full 
t$o name. When the compiler encounters such a symbol, it "desugars" it 
by following a simple rule: it produces t$o where t is the type of the 
first argument, and o is the operation name associated with the symbol. 
Thus "x + y" is desugared to "t$add(x, y)" where t is the type of x."

In CLU and Python, methods belong to the class/type rather than to the 
instances (as in C++ she claims).

"""Not only is this approach simple and easy to understand, it applies 
to both built-in and user-defined types uniformly. To allow sugars to be 
used with a new type, the type definer need only choose the right
names for the operations. For example, to allow the use of +, he or she 
names the addition operation "add." """

Also, CLU has exceptions that terminate and iterators used in for 

Terry Jan Reedy

More information about the Python-list mailing list