Re: more on delete from join

From: Kevin Kirkpatrick <kvnkrkptrck_at_gmail.com>
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

Original text of this message