Re: Declaring super types

On Apr 20, 2:07 am, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
> On Apr 19, 9:16 am, David BL <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Apr 19, 8:23 pm, Nilone <rea..._at_gmail.com> wrote:
>
> > > How would you want to use that relationship? Any examples to study?
>
> > 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.
>
> 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.

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.

> 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.

Yes and not just a syntactic asymmetry. Member functions defeat implicit coercions of *this. Received on Tue Apr 20 2010 - 04:13:14 CEST