Re: Types variables and values

On Oct 21, 8:23 pm, David BL <davi..._at_iinet.net.au> wrote:
> In An Introduction to Database Systems, C.J. Date, characterises
> value, variable and type as follows:-
>
> "value" : An "individual constant" - for example the individual
> constant that is the integer 3. A value has no location in time or
> space.
>
> "variable" : a holder for the appearance of a value. ... variables
> unlike values can be updated.
>
> "type" : a named set of values along with an associated set of
> operators that can be applied to values and variables of the type in
> question.
>
> According to Date, a type by definition is abstract, and should not be
> confused with a particular implementation of a type (which he calls a
> "POSSREP").
>
> It seems to me that these definitions are very important and useful
> but neverthess don't capture a general enough notion of "variable" and
> "type".
>
> That being said they're certainly appropriate for the topic of the
> book (Database Systems).
>
> In the following it is convenient to use C++ code examples, while
> tending to use Date's terminology.
>
> Firstly, let's agree that these definitions are perfectly adequate for
> the following types
>
> bool, int, float, string, Point, Circle, Ellipse
>
> I would call these "value-types", to distinguish from the following
> Mutex class:-
>
> class Mutex
> {
> public:
> void Lock();
> void Unlock();
> private:
> < locking thread id, lock count, queue of waiting
> threads ... >
> };
>
> Consider the following declaration
>
> Mutex m;
>
> Presumably we would say this declares a variable named 'm' of type
> Mutex. Is this compatible with Date's definition of "variable" and
> "type"?
>
> I would say it is inappropriate to regard a Mutex variable as holding
> a "value" that exists independently of the variable. That point of
> view raises more questions than answers...
>
> 1. What does it mean to assign a value to a mutex variable? Assume
> that the mutex variable is currently counting the number of times a
> particular thread has locked it, and it has queued a number of threads
> blocking in an efficient wait state on the call to Lock().
>
> 2. What operations exist on Mutex values?
>
> 3. What does it mean to copy the value in a mutex variable?
>
> I can think of lots of examples where I would say that a variable has
> state, but logically doesn't represent a "value".
>
> a A node of a double linked list or red black tree
> b A thread pool
> c A proxy for external hardware such as a printer or HDD
>
> These types are characterised by not supporting copy and assignment
> operations.
>
> Do Date's definitions apply reasonably to pointers? The answer would
> appear to be yes, because it is certainly useful (and common
> terminology) to distinguish between pointer types, pointer variables
> and pointer values. Pointer values can be assigned to pointer
> variables. Pointer values can be passed as arguments into functions,
> or returned from functions.
>
> However, there is something strange going on. We would normally think
> of values as existing independently of variables (and in fact the
> abstract machine), and yet a (non-null) pointer value represents a
> reference to a particular variable that exists in a particular running
> process on a particular machine.

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.

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

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.

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.

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

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.

Marshall Received on Wed Oct 24 2007 - 19:40:50 CEST