Re: Types variables and values

On Oct 25, 1:40 am, Marshall <marshall.spi..._at_gmail.com> wrote:

> Just some general comments and responses:
>
> Date's description of values is good. Also, different theories may
> have
> different things to say on the topic. ZFC set theory has only sets,
> and
> values are always sets. However there are other set theories that
> admit values that are not sets.

In my opinion the OO community ignores the importance of values and value-types. I particularly like Date's treatment of subtyping of value-types (which is about value substitutibility in contrast to variable substitutibility).

There was an interesting thread on the circle/ellipse question back in 2001, and I thought Bob Badour argued the case well.

I have wondered whether a C++ like language could support the following:

    float Perimeter(Rectangle r)
    {

        return 2*(r.Width() + r.Length());     }

where it is assumed that Rectangle is a value-type with no assumed implementation. Therefore the compiler treats Perimeter as a parameterised function. This allows the compiler to generate an implementation that simply returns the value 4 for a UnitSquare - because it is a subtype of Rectangle where Width() and Length() return 1.

This is getting our cake and eating it too : code reuse and efficiency. It's also more concise than explicit use of genericity such as with C++ templates.

> As far as variables go, I am hesitant about describing them as being
> necessarily "updatable" if by that we mean a destructive update
> operator such as destructive assignment. (As distinguished from
> initialization.) For example, consider:
>
> f(x) = x+1
>
> a = f(1)
> b = f(2)
>
> Inside the body of f, x takes on the value 1 in one case and 2 in the
> second case. One would expect to call x a variable, but x is not
> updatable in some formal systems. (In some programming languages
> x is an updatable entity that is initialized with a copy of the
> argument,
> but this is not always the case.)

Are you referring to FP where a variable can only bind to a value once?

Even in C++, I always get an uneasy feeling with functions that update the variables associated with formal arguments that have been passed in by value.

I agree that variables shouldn't be defined as necessarily updateable. In C++ one can use 'const' to declare variables that cannot be updated

    void f(const int x)
    {

        return x+1;
    }

I think the defining feature of a variable has to do with it having state and an address (or an identity, if you like).

>
> Date's definitions (and his writings in general) assume a "single
> level" model. Pointers and objects both introduce a multilevel
> model. An object is both a variable, in that it can be updated,
> and a value, the value being its identity. So you can have a
> program with a local variable, that is initialized with an object
> that is itself a variable. Code may update the variable to hold
> a different object, or the underlying object itself may be updated.
> So both of these constructs rather muddle the definitions of
> value and variable.

You just muddled me up as well :) This reminds me of Java where objects are passed around by reference by value!

    Point p = new Point(0,0); // In Java pointers are implicit

In my previous post I tried to avoid the term "object". Is the above standard terminology? I'm not entirely sure what it means to say that an object is both variable and value (= identity) at the same time.

I (now) tend to think of a variable as having identity and therefore there is no point introducing a new term "object" for what is essentially the same thing.

What do you think of the following definitions?

    value : as per Date
    val-type : set of values + operations on those values (as Date calls "type")

    variable : has state and address [but not necessarily a value]     var-type : type for a variable

Operations on values must not be confused with operations on variables.

val-type inheritance is distinct from var-type inheritance.

For every val-type there is a corresponding var-type for a variable that can hold values of that val-type. However the reverse is not true - there are var-types that don't correspond to any val-type.

> This raises the question of whether the multilevel model is
> a good idea or not. Various authors have pointed out a
> number of negative consequences of this idea. My personal
> experience bears out these arguments: local state in objects,
> (which is necessarily unmanaged, the very antithesis of data
> management) is a big source of bugs.

I agree that val-types are generally to be favoured. I think this also relates back to pure functional programming and the simplicity one achieves with functions that don't have side effects.

>
> However, from a programming language design standpoint,
> objects or something like them are devilishly hard to keep out.
> For example, the combination of updatable variables,
> first class functions and lexical scope combine to introduce
> what is effectively objects. (Namely, stateful closures.)
> If threads have state and can be communicated with, they
> are effectively objects. The killer is that these are all
> must-have features in my book. (I believe Date excludes
> first-class functions and doesn't address concurrency,
> but that's too harsh a solution for me.)

I guess a Mutex class is a practical example.

I can't say I understand exactly where (for example) pure functional programming reaches limitations. Over the years I have tended to use the latter style more and more in my OO programs, as if stateful objects should be treated as the "last resort". Unfortunately I haven't spent enough time thinking and doing FP to know what I might be missing!

> The real problem of objects from a data management
> view is that unlike simple values, objects can change.
> Imagine a relation with object values in it, and updating
> those objects without invoking updates on the relation.
> One imagines constraint checking would be bypassed.
> Yuck.

I think by definition, domains, tuples and relations are all valuetypes.   It seems to be one of the reasons why RM is so simple yet powerful. I guess it relates back to the general rule that surrogate ids should be avoided - never create identity that shouldn't be there in the first place. Received on Thu Oct 25 2007 - 05:33:04 CEST