passing by refference

[Terry Reedy]

"Fredrik Lundh" <fredrik at pythonware.com> wrote in message
news:mailman.1052920226.15446.python-list at python.org...

> 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.

<etc. rest of excellent extract>

Thanks for extracting this Fredrik.  With Python substituted for CLU
(and the other substitutions you mentioned), this is one of the
clearest descriptions of Python semantics I have seen (in over 6
years).  Anyone not crystal clear on Python's data model should save
this and reread periodically.

Terry J. Reedy

>
>     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>
>
>
>
>