Re: choice of character for relational division

On Apr 1, 7:37 am, paul c <toledobythe..._at_oohay.ac> wrote:
> Marshall wrote:
> > On Mar 31, 2:47 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> >>One needs to have set equality and set containment operators. If one has
> >>those, the query seems simple. What does a special operator for it buy one?
>
> > Do we need all of those? We need set equality for RVAs if we
> > want to join on RVAs (which we do) but do we need a top level
> > equality? I mean, I would expect it, but do we need it? Do we
> > ever ask in logic whether these propositions are the same as
> > those propositions? Doesn't seem so.
>
> > If we have equality (=) and join (&), we don't need containment:
>
> > A & B = A <=> A ⊆ B.
> > ...
>
> Yes, and to see if we have a proper subset I suppose something like:
>
> (A & B = A) & (A & B != B).
>
> Personally, I would rather not write that out very often and given the
> keyboard I have, I'm content to overload. In the above, which resembles
> a number of current languages, I think '&' is actually overloaded. In
> ordinary language or computer languages, it is types that tell what an
> op means, eg., people can be married and so can ideas but those are
> different kinds of marriages.

It certainly looks as if & is overloaded but ... maybe it isn't!

Suppose the relational = operator is closed over relations. That is, its result, rather than being some specific boolean type, was instead necessarily a relation. Any empty relation would be interpreted as false and any nonempty relation is true. In this case we don't need any attributes on the result, just to know whether it's empty or not. So

  true = DEE
  false = DUM

and the various & characters in the above are *all* natural join.

Likewise, the inner union operator can be written as | ... in the 0-arity case, it functions as boolean OR.

> Rather than write out the above to find a proper subset, I'd prefer to
> ask whether A < B? or A <= B? and use the above as the definition of A <
> B. But if I were writing a parser I think I'd let the user substitute
> their own symbols - they might not have a lowest-common-denominator
> keyboard like mine.

I figure it's a requirement to make something that's usable with just ASCII. But it's also be nice if it could format things prettily where possible. So maybe we have ASCII forms and unicode forms for some operators, and an easy way to go from one to the other.

-> →
=> ⇒
: ∈

and maybe
forall ∀
exists ∃

and maybe even
func λ

Fortress goes nuts with this idea, having three separate forms for source code, ascii, unicode, and go-nuts mathematical notation. That's too much for me, but I think some modest ascii/unicode translation is quite doable.

> I think Bob B is driving at a more important question - what ops should
> there be? There is a difference between having a small number of
> fundamental operators versus a small number of symbols that we use to
> ease expression.

Yes. In fact, this question isn't merely important; it is fundamental, critical.

Marshall Received on Sun Apr 01 2007 - 18:23:20 CEST