passing by refference
Fredrik Lundh
fredrik at pythonware.com
Wed May 14 09:49:09 EDT 2003
Joshua Marshall wrote:
> Also interesting that [call-by-sharing] is missing
did you read the "Why is this definition missing?" page?
(the FOLDOC maintainers add links to articles that should be written
some day, and keeps track of how many clicks the links get, so they
can focus on things that people really want to read about)
> For a good intro to semantics, I sugest
>
> Essentials of Programming Languages
> Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes
if all you have is scheme, etc.
> I'm not familiar with CLU
I suggest reading reference 3.
http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf
CLU is an important milestone in the development of OO languages;
to quote Liskov herself, from the above paper:
"The work on CLU, and other related work such as that on
Alphard, served to crystallize the idea of a data abstraction
and make it precise. As a result, the notion is widely used as
an organizing principle in program design and has become a
cornerstone of modern programming methodology."
if you don't know your history, etc.
> but I think this description of Python's argument-passing
> semantics is misleading.
did you read reference 1?
http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
in case your PDF reader is broken, here are the relevant portions from
that document (any typos etc added by me).
"The basic elements of CLU semantics are _objects_ and
_variables_. Objects are the data entities that are created and
manipulated by CLU programs. Variables are just the names used
in a program to refer to objects.
In CLU, each object has a particular _type_, which characterizes
its behavior. A type defines a set of operations that create
and manipulate objects of that type. An object may be created
and manipulated only via the operations of its type.
An object may _refer_ to objects. For example, a record object
refers to the objects that are the components of the record.
This notion is one of logical, not physical, containment. In
particular, it is possible for two distinct record objects to
refer to (or _share_) the same component object. In the case of
a cyclic structure, it is even possible for an object to
"contain" itself. Thus it is possible to have recursive data
structure definitions and shared data objects without explicit
reference types. /.../
CLU objects exist independently of procedure activations. Space
for objects is allocated from a dynamic storage area /.../ In
theory, all objects continue to exist forever. In practice, the
space used by an object may be reclaimed when the object isno
longer accessible to any CLU program.
An object may exhibit time-varying behavior. Such an object,
called a _mutable_ object, has a state which may be modified by
certain operations without changing the identity of the
object. /.../
If a mutable object _m_ is shared by two other objects _x_ and
_y_, then a modification to _m_ made via _x_ wil be visible when
_m_ is examined via _y_. /.../
Objects that do not exhibit time-varying behavior are called
_immutable_ objects, or constants. Examples of constants are
integers, booleans, characters, and strings. The value of a
constant object can not be modified. For example, new strings
may be computed from old ones, but existing strings do not
change. Similarily, none of the integer operations modify the
integers passed to them as arguments.
Variables are names used in CLU programs to _denote_ particular
objects at execution time. Unlike variables in many common
programming languages, which _are_ objects that _contain_
values, CLU variables are simply names that the programmer uses
to refer to objects. As such, it is possible for two variables
to denote (or _share_) the same object. CLU variables are much
like those in LISP and are similar to pointer variables in other
languages. However, CLU variables are _not_ objects; they
cannot be denoted by other variables or referred to by
objects. /.../
The basic actions in CLU are _assignment_ and _procedure
invocation_. The assignment primitive 'x := E' where _x_ is a
variable and _E_ is an expression, causes _x_ to denote the
object resulting from the evaulation of _E_. For example, if
_E_ is a simple variable _y_, then the assignment 'x := y'
causes _x_ to denote the object denoted by _y_. The object is
_not_ copied, it will be _shared_ by _x_ and _y_. Assignment
does not affect the state of any object. (Recall that 'r.s :=
v' is not a true assignment, but an abbreviation for 'put.s(r,
v)'.)
Procedure invocation involves passing argument objects from the
caller to the called procedure and returning result objects from
the procedure to the caller. The formal arguments of a
procedure are considered to be local variables of the procedure
and are initialized, by assignment, to the objects resulting
from the evaluation of the argument expressions. Thus argument
objects are shared between the caller and the called procedure.
A procedure may modify mutable argument objects (e.g. records),
but of course it cannot modify immutable ones (e.g. integers).
A procedure has no access to the variables of its caller.
Procedure invocations may be used directly as statements; those
that return objects may also be used as expressions. Arbitrary
recursive procedures are permitted."
replace "CLU" with "Python", "record" with "instance", and "procedure"
with "function or method", and you get a pretty accurate description
of Python's object model.
if you don't agree, please tell us what Python does differently. be very
specific.
</F>
More information about the Python-list
mailing list