Re: ID field as logical address
Date: Tue, 02 Jun 2009 14:26:03 GMT
Message-ID: <%DaVl.29079$Db2.27113_at_edtnps83>
David BL wrote:
> On May 31, 10:20 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
>> one of the many other confusions I snipped is that assignment is part of >> relational theory, whereas it's not, it is a concept certain kinds of >> languages need.
>
> If by "relational theory" you mean the relational algebra then it's
> true it doesn't include assignment. But obviously the sub-topic
> concerns the changes to a relational /database/ over time.
>
> This news group by definition concerns database theory. The main
> purpose of a database is to record values in variables. Whenever a
> variable is changed it has by definition been assigned with a
> different value.
>
> I doubt you'll take my word for, but perhaps you'll listen to Bob. The
> following quote comes from a post by Bob in Oct 2003:
>
> All D's are imperative. Imperative languages comprise
> those languages that operate by changing the state of
> variables. Since a database is a variable, imperative
> languages are entirely appropriate for data management.
> Regardless whether one writes expressions using the
> calculus or the algebra, one manages the data by
> changing the state of the database variable.
>
>
If you're trying to say RT allows languages that support pointers, okay. If you're trying to say RT requires an imperative style, eg., languages that support pointers, you're wrong. Tutorial D takes the arbitrary choice of aiming for the imperative style. You may as well say that a cpu that has some instructions that modify registers and some that indirect register contents can only support imperative languages. This may be hard for people who've never used assembler to see, but that's not my problem. Date calls Tutorial D algebraic but he doesn't say it's entirely algebraic. Functional languages are equally appropriate for an algebraic theory. Personally, I prefer names that amount to nothing more than macro-ized labels, this helps me think about programs instead of worrying about languages. SICP at the mit site, chapter three if I recall, talks about the sea change in comprehensibility that arises once assignment is introduced. Not only do I prefer to not have to think about statement order, I think most programmers are really no good at it. Just because db values vary doesn't mean one must implement variables and assignment. I think it is quite plausible that future generations will come to this view and laugh at today's self-imposed obstacles. Received on Tue Jun 02 2009 - 16:26:03 CEST