What's the view on whether a nominal type definition can declare
itself to be a super type of another type (even of a built-in type)?

E.g. suppose that INTEGER is a built-in type and we wish to define
type RATIONAL parameterised by (n:INTEGER, d:INTEGER) where n,d
represent numerator and denominator.

We seem to want to declare

INTEGER(n) isa RATIONAL(n,1)

which is analogous to

CIRCLE(c,r) isa ELLIPSE(c,r,r)

where ELLIPSE is parameterised in (c:POINT, a:NUMBER, b:NUMBER)

On Apr 19, 8:57*am, David BL <davi... (AT) iinet (DOT) net.au> wrote:
How would you want to use that relationship? Any examples to study?

On Apr 19, 8:23 pm, Nilone <rea... (AT) gmail (DOT) com> wrote:

For example, functions that accept RATIONAL values could be passed
values of type INTEGER.

It’s quite useful. E.g. even in a low level language like C there are
handy conversions amongst the built-in types:

double sqrt(double);

double x = sqrt(4); // integer 4 has implicit conversion to double

BTW C++ allows one to write user-defined value types supporting
implicit conversion from builtin-types, by writing single argument
constructors. Actually I just posted to comp.lang.c++.moderated
asking whether it can be regarded as a general purpose approach to
value subtyping in that language. But it does seem strange for a type
to declare itself as a supertype of another type.

On Apr 18, 11:57*pm, David BL <davi... (AT) iinet (DOT) net.au> wrote:
The right way to approach it is to take Maple, Mathematica or similar
system and to study how they are implemented it. As somebody put it an
ounce of math is worth a pound of CS.

On Apr 19, 9:16 am, David BL <davi... (AT) iinet (DOT) net.au> 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).

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.

C++ let's one think this way /most/ of the time (thanks to
overloading, template, etc). Unfortunately some operators must
be member functions which is an annoying asymmetry.

KHD

PS. The "no names allowed" thread became a total annoying mess
as soon as ill-defined nearly useless sub/super/duper language
crept in. (Not to say it wasn't on the verge of mess from the
very start ;-).

Keith H Duggar wrote:

[...]

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.

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

On Apr 19, 1:06*pm, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
Are you saying

"R is a S"

is eqivalent to

"R join S = R"?

On Apr 20, 2:07 am, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
If one can formalise a topic with fewer concepts then that has to be a
good thing. Are "coercions for a multi-sorted algebra" a standard
approach?

One needs some basis for choosing when coercions are allowed. Just
saying it is what it is (as part of a multi-sorted algebra) seems to
miss the intuition behind it to me (i.e. that there are terms that
represent alternative encodings of the same value under
interpretation).

Note that D&D use subtype=subset to for example deduce exactly what it
means for one tuple type to be a subtype of another. So they can
*explain* what implicit coercions should be allowed and what aren't.


Yes and not just a syntactic asymmetry. Member functions defeat
implicit coercions of *this.

On Apr 20, 4:06 am, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
I agree. Note that I didn't state INTEGER isa RATIONAL. Instead
INTEGER(n) isa RATIONAL(n,1)
which embodies the very specific sense in which we regard the integers
as being a subset of the rationals.
That doesn't fit my notion of is-a for data types. I agree with D&D's
subtype = subset. I don't think it's reasonable for implicit
conversions to "slice" or "project" (i.e. drop information). Of
course they shouldn't add information either.

Vadim Tropashko wrote:

Hmmm ... that seems a nice shorthand for the first and third clause,
but it doesn't imply the second one.

--
Reinier