Re: A Simple Notation

From: David Cressey <cressey73_at_verizon.net>
Date: Tue, 10 Jul 2007 14:35:36 GMT
Message-ID: <YOMki.3539$lY4.2820_at_trndny07>


"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:469395f4$0$8827$9a566e8b_at_news.aliant.net...
> David Cressey wrote:
>
> > "David Cressey" <cressey73_at_verizon.net> wrote in message
> > news:eirji.2$475.1_at_trndny04...
> >
> >>In reaction to Brian's responses, I'm going to reformulate the
notation,
> >>using OR and <OR> instead of AND and <AND>
> >
> >
> > After mulling this over for a while, I've reverted to my original
> > formulation, based on <AND>
> >
> > So:
> >
> > [A B] means <NOT> (A <AND> B) as I originally posted.
> >
> > I may yet be convinced by Brian's symmetry observation to map TRUE and
FALSE
> > the way he suggested, rather than the way I originally chose. I'm not
there
> > yet, but I'm not discarding his suggestion either.
> >
> > Why did I revert?
> >
> > Well, I like how easy it is to express a series of natural joins in the
> > original formulation:
> >
> > (A <AND> B <AND> C <AND> D) gets expressed as
> >
> > [[A B C D]]
> >
> > The extra pair of brackets simply provides a double negative.
> >
> > Consider a language vaguely like SQL, where one might have
> >
> > select <value-list> from <relational-expression> where <criterion>
> >
> > An example might be
> >
> > select
> > (LAST_NAME || ', ' || FIRST_NAME as NAME,
> > JOB_NAME as JOB_TITLE,
> > DEPARTMENT_NAME as DEPARTMENT)
> > from
> > [[ EMPLOYEES JOBS DEPARTMENTS ]]
> > order by
> > NAME;
> >
> > I know this isn't valid SQL syntax, but bear with me. This is an
imagined
> > language.
> >
> > We can allow any relational expression at all in the "from" clause.
That
> > means we can express unions, merges, or whatever in a single select.
But
> > natural joins, which we'll be doing more often than not, have a
> > particularly nice mode of expression, using this notation.
> >
> > Now I'm struggling with how natural joins work in a situation where
there is
> > more than one relationship between two tables. But that's a separate
issue.
>
> See D&D's comments regarding the necessity for RENAME.

Thanks. Received on Tue Jul 10 2007 - 16:35:36 CEST

Original text of this message