Re: Database-valued attributes?

Paul Vernon wrote:
> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> news:borjoh$1hdr38$1_at_ID-152540.news.uni-berlin.de...
>

>>Paul Vernon wrote:
>>
>>>So you are saying that you see no meaningful difference between

>>>and values?
>>>
>>>!
>>>
>>
>>First of all, variables are just a matter of convenience. There is no
>>intrinsic need for variables.

Time/State is a function from a (partial) order to states. Thus all you need is the functionm, and a dfunction is a value.

Please note that the entire mathematics, can do without our notion of variables ( variable for a mathematician means something else than for a programmer ).

> If we want to cater for (i.e. model)
> the reality that is the arrow of time, then we should, I suggest, see that
> at least one variable is intrinsic. Not considering time is, I suspect, a
> common reason why "theory"seems less practical in practice than in theory.
>

Well, not at all. In any case we were discussing whether we should or should not allow a "database" valued attribute,since that would imply "variables" (db,relvars, etc) where a value is expected.

>

>>Any algorithm that has variables (thus uses side effects) can be
>>rewritten as an algorithm that doesn't use variables (side effect free,
>>or purely functional). And no significant effort is required for that,
>>often time is just a change of paradigm and often time the quality of
>>code improves..

Oh, but they do. It's just a difference of perception. What in imperative programming is considered a "step", i.e. a transition of the abstract machine for which we have defined the operational semantics of the language, corresponds to a reduction step in lambda calculus, or corresponds with applying deduction rule in various logical calculi (like Hilbert Natural Deduction).

Now imagine that you define the semantics of an imperative language in a denotational settings, for example using Dijkstra's predicate transformers. Now all of a sudden time disappears from the semantics of the imperative language, and is replaced by a logical calculus.

> A relation expression takes the current value of the database variable as
> input, and outputs (at some subsequent point in time) the result of the
> relational expression. The database holds the state of the universe of
> discourse at each point in time, but we can only ever read the current
> state - anything else is not a good model of reality, because we cannot go
> back in time (or go forward without waiting).
>

Yes, and we may as well model that alternatively as a function transforming a (possibly infinite ) stream of events (user inputs) to the corresponding stream of states.

Add to that a initial state, and that's it. Nothing to write home about.

> The database variable is a good model of our reality as it reflect the
> facts:
>
> o That information exists now and will still exist at now + 1 if nothing
> acts to remove or create it
>
> o That we cannot know what information existed at any time previous to
> now, if we have now not got the information about what information existed
> at previous times.
>
> o That we cannot know anything about what information will exist at
> future times unless we have constraints on what information can exist in the
> future (and agree not to alter such constraints as frequently s the
> infromation that they constrain)
>
> You cannot model these facts without the concept of a variable IMO.

Oh, but you can. You can either operate on transformers of infinite streams, or alternatively you can use "unique" or "linear" variables where the formalism guanratees that the "variable" is assigned exactly once (not much of a variable, is it ?). This concept was derived from Jean ves Girard "Linear Logic" and applied for example in the functional language Clean. Yet you can model these features using the concept of monads from the theory of category as is done in Haskell. Monads really are nothing fancy, just a mathematical shortcut to allow for easier composition of computations with effects (I/O, side effects, exceptions, etc), albeit an improtant one.

> If you
> make 'time' just another value, then you cannot model these facts. Don't get
> me wrong, time is a value (and should be represented as such), but it more
> than that, it also defines a variable.
>

The problem is that everbybody around here cries so much about the distinction between variable and value, and all started from Date and Darwen claim, but in the absence of any proper formalism to define the context and the terminology.

What's a variable ? In a pure functional language, it is nothing at all. In an imperative language it is a name bound to a context (no variable can live outside a context) that maps to a value.
>

>>But even in a classical programming language setting where you have
>>variables, you can set asside the variables and as variables and look at
>>them as entries in a context, the context being always an implicit
>>parameter in the call chain (or call stack if there is a stack). The
>>context can then be accessed like any other map value.

>>I'm also curious, do you have a definition for variable ?

The database is the context that defines the relvars. A context at one point in time is just a value ( a map more precisely ).

Now if you have no problem supporting UPDATE as an operator to change an integer attribute from 1 to 2, then you should have no problem supporting the same UPDATE operator to change a context value, from the old value of the "database" to the new value of the "database".

> Regards
> Paul Vernon
> Business Intelligence, IBM Global Services

best,
Costin
>
>

Best,
Costin Received on Wed Nov 12 2003 - 20:43:05 CET