Re: globals besides relvars?

From: Bob Badour <>
Date: Mon, 28 Jul 2003 14:55:12 -0400
Message-ID: <dkfVa.1371$>

"Marshall Spight" <> wrote in message news:WqcVa.148132$GL4.38052_at_rwcrnsc53...
> "Bob Badour" <> wrote in message
> > "Marshall Spight" <> wrote in message
> > news:eX0Va.143552$GL4.37155_at_rwcrnsc53...
> >
> > > So what if you have some function that requires some storage?
> >
> > No 'function' requires global state information.
> What about functions that have access to the database?

A function has access to its parameters. No function needs access to the database except as a parameter.

> Are they
> disallowed too?

Are database parameters allowed? I assume so.

> Note that a function that accesses the database
> is accessing global state information.

Everything ultimately accesses global state information. The question is: Does it access it explicitly as global state information or does it access the state information as an argument to a well-defined parameter.

> > Your problem is imagining that this simple datum is a function.
> And why is it not a function?

It is a simple datum. Why is it a function? A function of what?

> Would you consider it acceptable
> if I called it an operator or a procedure? (In most programming
> languages, it would be called a function.)

My first question is: An operation on what? One could conceive a design where the possible representation of a user includes the user's current timezone. In this case, the timezone is an operation on a user type. Since one supplies a user value when one invokes the operation, it requires no access to global state information. One wonders, though, what design criteria would cause one to choose such a design.

> > > It needs to store this somewhere.
> >
> > One would represent the datum as a value in a global relvar, and one has
> > need for a function.
> For many things, a functional expression is better than the relational
> equivalent.

Your assertion is frankly unsupportable.

> For example, I'd rather invoke the getTimeZone() function
> than:
> Select * from TimeZone
> unwrap relation into tuple
> unwrap tuple into value

What makes you think that one would have a TimeZone relvar? TimeZone is simply an attribute of a relvar, and I fail to see why one would need to unwrap it to use it.

If one allows a globally distributed database, one must ask what this timezone is? The database does not have a single unique timezone. Perhaps, it is part of the user context.

EXTEND ( CurrentUser{ Name, TimeZone } JOIN System{ Now } ) ADD String( Now , TimeZone ) AS LocalNow

> > You presume incorrectly. There is a timezone attribute in a global
> > with an empty candidate key.
> (I talked about this in another post.)

If I happen to see the other post, perhaps, I will straighten out your faulty presumptions there.

> > > Where does it store the timezone?
> >
> > We don't care. How it represents the datum matters. Where it stores it
> > not matter at all.
> Okay, I'm talking about the logical model of things. I don't know what
> I'm doing that makes you think I'm talking about implementation, but
> I'm not.

Then stop using verbs like 'to store' that imply physical aspects like storage. The logical model speaks to how one represents data and not to how one stores it.

> There's nothing about the word "store" than mandates an
> implementation meaning. I can logically store some information just
> as well as I can store it on a disk sector.

After you explain to me how you can speak about storing something without any reference to a storage location, I'll reconsider my opinion. Until then, I will continue to reserve storing for the physical and representing for the logical.

> > > But if this is allowed, isn't it starting to sound like objects?
> >
> > Objects require tightly bound storage. Relations allow it. There is a
> > difference.
> So relations allow tightly bound storage. Can you expand on what
> you mean by this? Or do you mean this as an implementation technique?

Relations allow any kind of storage. The relational model imposes no restrictions on physical storage. One can choose physical storage that directly stores base relations without any redundancy, or one can choose any other physical storage from which one can derive base relations regardless of redundancy. One can choose physical storage that at first glance does not resemble relations in any way. One can store a 10-ary relation with 10 parallel arrays, for instance.

> > Since the physical storage is not exposed to the user, there is no
> > measurable state. Logically, a function is pure behaviour.
> Don't functions have access to the database?

Why should they have access to anything except their parameters?

> Or do some of them
> have this access? *Some* code somewhere has to be able to
> access the database, and this code won't be dependent on its
> formal parameters alone; it will also depend on "global state"
> aka the database.

External application code certainly has access to the global state of the database, but even this could be parameterized.

> I'm groping my way towards a model where the concept of a
> programming language's global variables and the concept of
> the database are merged. They perform the same function; no
> need to have both concepts. Clearly the database world has
> the better notion of global state anyway.

I suggest that they perform different functions. For instance, an application's global variables generally do not persist across executions of the application. There are strong arguments for severely restricting the use of global variables in application programming languages, and equally strong arguments for maximizing the use of global variables in database management systems.

In a sense, the need for managing global, persistent state separately from applications is what drives the need for data management systems in the first place.

> > > Earlier I was thinking about operator identity. (The + operator
> > > has zero as the identity value; multiply has 1.) This seems
> > > like it associates with a function as well. But this idea doesn't
> > > seem so problematic, because it's just a constant.
> >
> > The identity value for an operator exists even if one doesn't store it.
> True, but I might need to access it in order to implement some
> For example, the reduce function (a pure function I might add) applied
> to "plus" and a list of integers. (This adds up all the ints in the list.)
> In the functional languages I've seen, they require you to pass
> an additional parameter that is the "basis" for the reduce.
> This is the value to return if the list is empty. To me, this is just a
> extra argument to make up for the fact that the language isn't expressive
> enough to record the fact that the operator has an identity value, and
> to make it available to 'reduce'.

One can derive an aggregate function from any commutative, associative operation with an identity value. As such, there are arguments for representing the identity values of such operations, and perhaps the operation is part of the possible representation of some subtype of an 'operation' type. Received on Mon Jul 28 2003 - 20:55:12 CEST

Original text of this message