Re: Nested Relations / RVAs / NFNF

"Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:<rrChd.24$J%6.180_at_news.oracle.com>...

<snip>

> Well, I don't buy postulate "type is orthogonal to relation" until I
> understand what type is;-)
>

Where's Costin when you really need him ;) ? For the moment I'll restrict myself to the naive "set of values, or equations describing the set of values, plus operators over them". The argument is that it makes no difference to relations what types the various attributes are - they still work the same way in all cases.

> > Also, this doesn't address the point above; what I was saying was that
> > our languages are generally poor at adding new symbols.
>
> I still dont understand your question:-\ But I can give you the answer what
> units are:-)
>

The question being raised was, if we can express values like £2.63, or $3.75, or 2.0kg, or even 3lbs 4oz, why can't we use those values in programming languages and databases ? Why should we have to say things like kg(2.0), or (lbs 3 oz 4), or other nasty kludges ? Because parsers weren't readily alterable to include new types & symbols 30 years ago, or whatever ? Mr Neo provided one approach to this question elsewhere in the thread. I wasn't grossly impressed.  

> I disagree. Civilization progress so far has been along generalizing
> concrete objects into abstract concepts. This is how we've got the concept
> of number. We manipulate numbers without being forced to constantly
> typecheck:
>
> 2 cows + 3 bulls = a herd of 5
>

Yes, but what is the type of 2 cows + 3 cats ? Also, what are the types actually being handled here ? Integers, or cows and bulls ? Is it legal to divide cows by bulls ? (Multiplication is obviously possible ;) And we probably do type-check these kinds of things, but it's such a low level thing we hardly notice it, until the types are different (e.g. work out in your head what 87.2 kilograms minus 2 pounds 3 ounces is).  

<snip>

> How do we handle conversions:
>
> http://tinyurl.com/68rbm
>

On a quick read, this had the look of a kind-of clever hack to handle a problem that needs a fundamental review.  

<snip>

> > Why should SQL per se have a type engine ? The type engine is a thing
> > existing outwith the relational operators. For example, I would see
> > the above query being executed along the lines of ...
> >
> > 1. relational engine performs a natural join of cars and routes
> > 2. it checks that a divide function has been defined over the types of
> > distance and velocity, and that the result of that divide has a less
> > than or equal to operator defined on it
>
> This rule looks arbitrary.
>

It isn't; if you don't do something like this, you're into the C hinterland of calling functions with whatever values you have to hand and hoping for the best. You need to do something like this to know that any expressions you evaluate are well typed.

> > 3. for each tuple in the result set, call whichever function
> > implements the division
>
> Why do we need polymorphic dispatch? Why OO perspective is relevant to the
> issue here at all?
>

Well, it's not really OO - not all that handles polymorphism is OO, after all. You need to do this to know that the sub expressions are type sensible (e.g. you're not multiplying a string by a list, say). And if you have an overloaded operator (like +,-,* and / usually are) you need to make sure you use the right one.

<snip>

> Again, division is fundamental arithmentics operation that doesn't require
> multiple implementations. As my previous link indicates, all arithmetic
> operations can be extended to accomodate units symbols as well!

Indeed; if you have something physically represented by integers, and division is permissible for the type you're modelling, then you can go ahead and use integer division, under the covers. But division (or multiplication, or square, or mod, or whatever) may not be permissible operations for your new type, so shouldn't be available.

Cheers,

• Tony