# Re: more on delete from join

Date: Sat, 29 Aug 2009 09:45:58 -0700 (PDT)

Message-ID: <cb3a626b-70c1-44ca-aec2-7a65cb69aa45_at_h30g2000vbr.googlegroups.com>

On Aug 29, 10:32 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:

> On Aug 29, 9:45 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

*>
**>
**>
**>
**>
**> > Kevin Kirkpatrick wrote:
**> > > On Aug 28, 6:29 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
**>
**> > >>Kevin Kirkpatrick wrote:
**>
**> > >>>On Aug 28, 4:32 pm, paul c <toledobythe..._at_oohay.ac> wrote:
**>
**> > >>>>Kevin Kirkpatrick wrote:
**>
**> > >>>>...
**>
**> > >>>>>>By the way, why assume that CURRENT_USER
**> > >>>>>>is not updateable?
**>
**> > >>>>>Great question, cuts to the heart of the matter: It can't be updated
**> > >>>>>because it is a view. It returns an conclusion, and it is not (IMO)
**> > >>>>>valid to assert conclusions. ...
**>
**> > >>>>So A UNION B is a conclusion when assigned to a view, but not a
**> > >>>>conclusion when assigned to a base. Where does this idea come from and
**> > >>>>what is it good for, apart from appearing to be a spurious reason to say
**> > >>>>that views aren't updateable? Even if I were to accept that views
**> > >>>>aren't updateable, I'd ask why is CURRENT_USER necessarily a view?
**>
**> > >>>>(Personally, I would prefer an engine that allows a user to log himself
**> > >>>>off by means of a simple delete rather than the usual arcane engine
**> > >>>>plumbing that introduces various environmental commands. That way, the
**> > >>>>environment is forced to react to db changes rather than the other way
**> > >>>>around. The engine becomes much simpler if this approach is followed
**> > >>>>and this is important if there's ever to be any progess in the aspects
**> > >>>>that today's engines slough off.)
**> > >>>>...
**>
**> > >>>My point, phrased another way, is: given base relvars A, B, and C with
**> > >>>identical headings, this does not make sense:
**>
**> > >>>(A UNION B) := (B UNION C)
**>
**> > >>>in the exact same way that this does not make sense:
**>
**> > >>>int x, y;
**> > >>>x+y := 3;
**>
**> > >>But computers do solve systems of equations:
**>
**> > >>x+y = 3
**> > >>x-y = 1
**>
**> > > Well, I will grant that. But there is an difference between
**>
**> > > exp[0]:='x+y = 3'
**> > > exp[1]:='x-y = 1'
**> > > print(Solve_system (exp, 'x')); -- prints 2
**>
**> > > and
**> > > x+y := 3;
**> > > x-y := 1;
**> > > print (x); -- prints 2? (does it? can it? see below...)
**>
**> > I agree. The former is klunky and inelegant while the latter is elegant
**> > and clear.
**>
**> What should these clear and elegant programs print?
**>
**> int x, y;
**> y:=3;
**> x:=y;
**> print (x);
**> y:=4;
**> print (x);
**> --------
**> int x, y;
**> y:=3;
**> x+y:=5;
**> print(x);
**> y:=4;
**> print(x);
*

On Aug 29, 10:32 am, Kevin Kirkpatrick <kvnkrkpt..._at_gmail.com> wrote:

> On Aug 29, 9:45 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

*>
**>
**>
**>
**>
**> > Kevin Kirkpatrick wrote:
**> > > On Aug 28, 6:29 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
**>
**> > >>Kevin Kirkpatrick wrote:
**>
**> > >>>On Aug 28, 4:32 pm, paul c <toledobythe..._at_oohay.ac> wrote:
**>
**> > >>>>Kevin Kirkpatrick wrote:
**>
**> > >>>>...
**>
**> > >>>>>>By the way, why assume that CURRENT_USER
**> > >>>>>>is not updateable?
**>
**> > >>>>>Great question, cuts to the heart of the matter: It can't be updated
**> > >>>>>because it is a view. It returns an conclusion, and it is not (IMO)
**> > >>>>>valid to assert conclusions. ...
**>
**> > >>>>So A UNION B is a conclusion when assigned to a view, but not a
**> > >>>>conclusion when assigned to a base. Where does this idea come from and
**> > >>>>what is it good for, apart from appearing to be a spurious reason to say
**> > >>>>that views aren't updateable? Even if I were to accept that views
**> > >>>>aren't updateable, I'd ask why is CURRENT_USER necessarily a view?
**>
**> > >>>>(Personally, I would prefer an engine that allows a user to log himself
**> > >>>>off by means of a simple delete rather than the usual arcane engine
**> > >>>>plumbing that introduces various environmental commands. That way, the
**> > >>>>environment is forced to react to db changes rather than the other way
**> > >>>>around. The engine becomes much simpler if this approach is followed
**> > >>>>and this is important if there's ever to be any progess in the aspects
**> > >>>>that today's engines slough off.)
**> > >>>>...
**>
**> > >>>My point, phrased another way, is: given base relvars A, B, and C with
**> > >>>identical headings, this does not make sense:
**>
**> > >>>(A UNION B) := (B UNION C)
**>
**> > >>>in the exact same way that this does not make sense:
**>
**> > >>>int x, y;
**> > >>>x+y := 3;
**>
**> > >>But computers do solve systems of equations:
**>
**> > >>x+y = 3
**> > >>x-y = 1
**>
**> > > Well, I will grant that. But there is an difference between
**>
**> > > exp[0]:='x+y = 3'
**> > > exp[1]:='x-y = 1'
**> > > print(Solve_system (exp, 'x')); -- prints 2
**>
**> > > and
**> > > x+y := 3;
**> > > x-y := 1;
**> > > print (x); -- prints 2? (does it? can it? see below...)
**>
**> > I agree. The former is klunky and inelegant while the latter is elegant
**> > and clear.
**>
**> What should these clear and elegant programs print?
**>
**> int x, y;
**> y:=3;
**> x:=y;
**> print (x);
**> y:=4;
**> print (x);
**> --------
**> int x, y;
**> y:=3;
**> x+y:=5;
**> print(x);
**> y:=4;
**> print(x);
*

One final example - what does this print:
int x, y;

x:=6;

y:=3;

x+y :=8;

print(x);

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. Perhaps my "off the cuff" notation using exp[] arrays was kludgy... would this be a more elagant and clear language?

int x, y;

invariant x+y=6; --- not an assignment

y := 7;

print (x); -- prints -1

print (y); -- prints 6

x:= 5;

print (x); -- prints 5

print (y); -- prints 1
Received on Sat Aug 29 2009 - 18:45:58 CEST