passing by refference

Doug Quale quale1 at charter.net
Thu May 15 18:42:24 EDT 2003


"Fredrik Lundh" <fredrik at pythonware.com> writes:

> Joshua Marshall wrote:
> 
> > 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.

It's a good reference to programming languages in general.  The
authors are prominent researchers in the field.  Scheme provides a
good basis for discussing many programming language concepts, although
its syntax doesn't demonstrate very much about issues involved in
parsing.  From the description you give below CLU doesn't offer much
more.

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

Same as Scheme and Lisp.

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

Same as Scheme and Lisp.  Types are associated with objects (values),
not variables.  This is strong dynamic (or latent) typing.  (CLU might
be statically typed since you can't tell from these excerpts, but I
suspect that it is dynamically typed.)

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

Same as Scheme and Lisp.

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

Indefinite extent + garbage collection, same as Scheme and Lisp.

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

Same as Scheme and Lisp.  Note that in pure functional languages all
values are immutable.  Scheme and Lisp are not pure.

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

Same as Scheme and Lisp except that strings are mutable in those languages.

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

Same as Scheme and Lisp.  Same as C treatment of arrays and pointer
values.

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

Same as Scheme and Lisp, although naturally the syntax is different.
Scheme uses (define x E) and (set! x E) for assignment.  Lisp uses
(setq x E).

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

This is a description of call-by-value using CLU values (object
references).  Note that CLU values used in variable assignment and the
binding done by argument passing are the same.  This is the key point.

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

It describes Python very well.  Since it also describes a
call-by-value argument passing semantics, one can conclude that CLU
and Python, like Scheme and Lisp, are call-by-value.

If you don't agree that this describes call-by-value argument passing,
tell us what Python does differently.  Be very specific.




More information about the Python-list mailing list