Re: globals besides relvars?

From: Marshall Spight <>
Date: Tue, 29 Jul 2003 03:52:23 GMT
Message-ID: <XbmVa.5101$>

"Bob Badour" <> wrote in message news:dkfVa.1371$
> "Marshall Spight" <> wrote in message
> news:WqcVa.148132$GL4.38052_at_rwcrnsc53...
> > > 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.

Some code somewhere needs to access the database. Application code needs to access the database. If there isn't some way for code to access the database, then the database is useless.

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

Where did the calling code get access to the 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?

Every simple datum is also a well-formed function: the function of zero inputs and the datum as output.

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

Even TTM admits to the necessity of having these unwrap operators.

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

I appreciate your magnanimity.

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

"Joe, here's a bunch of information about our users and what timezones they are in. Could you store it in the database, please? Use the timezone table."

> Until then, I will continue to reserve storing for
> the physical and representing for the logical.

Well, now we each know what the other thinks the word "store" means. I note that searching Google for "stored in {a|the} {file|database}" returns more hits for the database use of the word than the file use of the word, so I think common usage, at least, is against you. (Not that common usage is definitive.)

> > Don't functions have access to the database?
> Why should they have access to anything except their parameters?

Because the database is just full of useful information. Functions which have access to this information will be able to do more useful things than functions which don't have access to it.

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

Well, yeah, that's how everyone thinks about it now. I think that makes database access unnecessarily complicated, though. Why do we need a separate model for global data in applications, and persistent data in applications? I note that databases often support temp tables.

Marshall Received on Tue Jul 29 2003 - 05:52:23 CEST

Original text of this message