Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: globals besides relvars?

Re: globals besides relvars?

From: Marshall Spight <mspight_at_dnai.com>
Date: Mon, 28 Jul 2003 16:45:42 GMT
Message-ID: <WqcVa.148132$GL4.38052@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? Are they disallowed too? Note that a function that accesses the database is accessing global state information.

> Your problem is imagining that this simple datum is a function.

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

> > 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. For example, I'd rather invoke the getTimeZone() function than:

Select * from TimeZone
unwrap relation into tuple
unwrap tuple into value

> You presume incorrectly. There is a timezone attribute in a global relvar
> with an empty candidate key.

(I talked about this in another post.)

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

> > 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?

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

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.

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

Marshall Received on Mon Jul 28 2003 - 11:45:42 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US