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>


Kevin Kirkpatrick wrote:

> 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

Original text of this message