# Re: more on delete from join

From: Bob Badour <bbadour_at_pei.sympatico.ca>

Date: Sun, 30 Aug 2009 17:31:22 -0300

Message-ID: <4a9ade0b$0$23762$9a566e8b_at_news.aliant.net>

>>On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

>>On Aug 30, 7:15 am, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

Date: Sun, 30 Aug 2009 17:31:22 -0300

Message-ID: <4a9ade0b$0$23762$9a566e8b_at_news.aliant.net>

> On Aug 30, 12:39 am, Marshall <marshall.spi..._at_gmail.com> wrote: >

>>On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

*>>**>>**>>>"Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message**>>**>>>news:cb3a626b-70c1-44ca-aec2-7a65cb69aa45_at_h30g2000vbr.googlegroups.com...**>>**>>><snip>**>>**>>>>I'm not saying the notion of a programming language solving systems of**>>>>equations is undesirable. But I am saying that the language needs**>>>>more than just assignments to get you there.**>>**>>>I think you're making the same mistake as Bob. Assignments aren't**>>>equations.**>>**>>I see no evidence that Bob has trouble telling assignments and**>>equations apart.**>>**>>**>>>x := x + 1 definitely not an equation.**>>**>>Of course it isn't.**>>**>>**>>>It may be desirable to have a programming language that can solve systems of**>>>equations, but....**>>**>>>x + y := 3 definitely not an equation.**>>>x - y := 1 definitely not an equation.**>>**>>Whether it is an equation or not depends on what those**>>symbols you typed are supposed to mean. So far all**>>you've said is that they aren't equations. However they**>>are both closer in form to equations than to assignments,**>>according to custom.**>>**>>**>>>The result?**>>**>>>x = 2 and y = 1? possible.**>>>x = 503423 and y = 503422? also possible.**>>>x = -324 and y = -325 also possible.**>>**>>But you said above that they were *not* equations,**>>so where are you deriving these from?**>>**>>**>>>I think it defies logic for assignment to be anything but deterministic.**>>**>>No one has said anything about nondeterminism that I've seen.**>>**>>Marshall*> > > On Aug 30, 12:27 pm, Marshall <marshall.spi..._at_gmail.com> wrote: >

>>On Aug 30, 7:15 am, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

*>>**>>**>>>"Marshall" <marshall.spi..._at_gmail.com> wrote in message**>>>On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:**>>**>>>>>I think you're making the same mistake as Bob. Assignments aren't**>>>>>equations.**>>**>>>>I see no evidence that Bob has trouble telling assignments and**>>>>equations apart.**>>**>>>Then why did he bring up solving systems of equations in the**>>>context of view updates?**>>**>>Probably because there are many interesting things to learn**>>from considering view updates as being related to solving**>>systems of equations.**>>**>>Normally when we say someone has trouble telling two**>>things apart, we mean that they are using them interchangeably**>>without paying attention to their distinctions.**>>**>>**>>>>>x + y := 3 definitely not an equation.**>>>>>x - y := 1 definitely not an equation.**>>**>>>>Whether it is an equation or not depends on what those**>>>>symbols you typed are supposed to mean. So far all**>>>>you've said is that they aren't equations. However they**>>>>are both closer in form to equations than to assignments,**>>>>according to custom.**>>**>>>The expressions are malformed in either sense.**>>**>>They are your expressions. If you meant them as unparseable**>>nonsense, then you cannot draw any conclusions from them.**>>**>>**>>>>>The result?**>>**>>>>>x = 2 and y = 1? possible.**>>>>>x = 503423 and y = 503422? also possible.**>>>>>x = -324 and y = -325 also possible.**>>**>>>>But you said above that they were *not* equations,**>>>>so where are you deriving these from?**>>**>>>They are not derived. They are picked out at random from the infinite**>>>combinations of values that add up to 1, the rhs of the final assignment.**>>**>>OK. So that means you are using the things of which you said**>>"definitely not equations" as equations. Is it possible that you**>>are using assignment and equations interchangeably and not**>>attending sufficiently to their differences?**>>**>>**>>>Doesn't the Assignment Principle require that the lhs of an assignment after**>>>execution be equal to what the rhs evaluated to before?**>>**>>I am unfamiliar with any "Assignment Principle." However what**>>you describe does match the semantics of assignment in many**>>imperative languages.**>>**>>This stuff is not dogma. We can make up languages that do**>>whatever we want; it is up to us to say what they do and**>>to decide if they do what we want.**>>**>>**>>>>>I think it defies logic for assignment to be anything but deterministic.**>>**>>>>No one has said anything about nondeterminism that I've seen.**>>**>>>The system having to guess what the user intended is a direct**>>>consequence of view updates being nondeterministic.**>>**>>It is still the case that you are the only one bringing up**>>nondeterminism.**>>No one has proposed any nondeterministic semantics.**>>**>>**>>>For example, an insert into a union**>>>view involving two tables is not deterministic because there are three**>>>different combinations of values that could result in the same value for the**>>>view. The system has to guess whether the row must be inserted into one**>>>table or the other or both. The same can be said of a delete from a join**>>>view.**>>**>>That would be one way to do it, but you are the only one talking about**>>doing it that way, and it is, as you say, a poor choice of how to do**>>it.**>>This is what's called a strawman argument.**>>**>>Some systems of equations are overspecified, some are underspecified,**>>and some are uniquely specified. Which one of those do you think**>>might be a good candidate for the kind of view update that**>>would succeed? Would fail?**>>**>>Marshall*> > Okay, I'll take another stab at this. > > BASE RELATION T := {TUPLE {C1='X'}}; > > VIRTUAL RELATION V := 'T'; > > INSERT INTO V {TUPLE {C1='Y'}} > > There seem to be two ideas of how a statement like this, if allowed > into the langauge, could be interpretted. > > First, there's the relational assignment interpretation, which > attempts to treat this insert into V exactly as if it were an insert > into a base table. My objection to this interpretation was: an INSERT > into a base table can be considered a shorthand for an assignment to a > base table. However, if one attempts to turn the INSERT into V into > an assignment, one gets a view variable on the left hand side and a > relation-value on the right-hand-side, which is clearly a nonsensical > type-violation.

Not so. A view is a named relation variable. Received on Sun Aug 30 2009 - 22:31:22 CEST