Re: ID field as logical address

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:%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.

I suggest that you re-read chapter three of SICP. I think I've suggested that before, but if you really don't want to be the subject of ridicule, I recommend a close revisitation. In particular, I suggest you focus on their example involving the current balance of a bank account, since housing current state is the primary function of a database. I suggest, as does the author of SICP, that the functional programming paradigm is contraindicated for this purpose.

It's humorous, really, that you juxtaposed me and Mr. Celko in a previous post, but now provided me an opportunity to reciprocate by pointing out that in the same way that Joe Celko, in his canned posts, cited works that he thought supported his argument when they in fact undermined it, your reference to chapter 3 of SICP effectively undermines your argument. Received on Tue Jun 02 2009 - 20:02:10 CEST