Re: Declaring super types

Keith H Duggar wrote:

[...]

>As you've already pointed out, conversions neither require sub/
>super/duper typing nor do they define them. Such "inheritance"
>notions get in the way of clear thinking far more than they help
>(actually that's true of most hierarchal notions to begin with).

By way of illustration: some time ago I needed a 100K codebase in VB.NET converted to C# and I found a conversion tool to do it. It was worth the money, but perfect it was not. Some constructs it refused to convert; on some constructs it produced code that wouldn't compile. But worst of all, occasionally it would produce code that compiled perfectly well, and was still wrong. For instance,

  3/2

was converted to, can you guess it,

  3/2

Wrong! These expressions do not denote the same value in VB.NET and C#.

What is the problem here? Can we put the blame on any of the two languages for interpreting this expression "wrong"? I don't think so. I think the problem is exactly what Keith writes: just saying that an integer number "is a" rational number doesn't tell us all that much. It doesn't tell us the value of 3/2, for one thing.

What we can do is pick an exact, formal definition of what "is a" means and apply it consistently. The results are probably going to be counterintuitive in some cases but at least well defined and consistent.

>In other words, totally drop these notions of sub/super/duper
>type and most if not everything is simpler and more clear. In
>this specific case there would simply be a function signature
>
> () : INTEGER -> RATIONAL
>
>declared somewhere with some name or anonymous as above that
>defines a coercion for this multi-sorted algebra. That is it.
>No more, no less, no need for sub/super/duper thinking at all.

Yes. Then again. "is a" does have a simple, useful and consistent definition for the relational model: for relvars R, S, we can write

  R is a S

as a shorthand for:

  + all attributes of S are attributes of R;
  + those attributes are a (possibly super)key of R, and
  + R projected on those attributes is always a subset of S.

This completely sidesteps any considerations on the semantics of, or operations on, domain values, which is what I was taught "the relational approach" is all about. So that is my answer to David's question.

-- 
Reinier