passing by refference

[Fredrik Lundh]

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>