"Jim Starkey" <jas@...> wrote:

>
> There's a syntax problem with this. The statement "select * from xyz
> where modified(a,b)" doesn't parse with the current grammer unless the
> parse knows that "modified" is a boolean valued function rather than
> scalar valued. On the other hand, building in a pseudo function doesn't
> fit well with the meta-grammar (but could be done).

We already have INSERTING/UPDATING/DELETING pseudo-booleans implemented in
the parser.

> I don't buy the C++ argument at all. First, the semantics of the
> proposed == is much closer to the C++ == operator than the C++ =
> (assignment) operator. Second, the proposed == operator is what
> programmers intend to write 95% of the time anyway. When comparing
> against a literal, there is almost no difference. The only time that
> significant differences can be expected is when it is used as a join
> term, and in many case, it's also probably closer to what the programmer
> intended. If a C++ programmer can master <> instead of !=, I think he
> or she can back a == operator that behaves like a == operator.

I expect to have some fun seeing you attacked by programmers trying to write
a negated equivalence operator. Yeah, especially those who can master <>
instead of !=. They'll initially try <><> or <<>>, then !=!= or !!== or
!==... When (or perhaps if?) they'll come to "not <a> == <b>", our support
list will die.


Dmitry