Re: globals besides relvars?

"Marshall Spight" <mspight_at_dnai.com> wrote in message
news:WqcVa.148132$GL4.38052_at_rwcrnsc53...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:VFbVa.1355$SM1.246363243_at_mantis.golden.net...
> > "Marshall Spight" <mspight_at_dnai.com> 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
no
> > need for a function.>> For many things, a functional expression is better than the relational> equivalent.

> > You presume incorrectly. There is a timezone attribute in a global
relvar
> > 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
does
> > 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
big
> > 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
functionality.
> 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
goofy
> 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 - 13:55:12 CDT