[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Co-/Contravariance (was: mandatory newbie musing)
From: |
Norbert Nemec |
Subject: |
Re: Co-/Contravariance (was: mandatory newbie musing) |
Date: |
Fri, 6 Oct 2000 10:59:20 +0200 |
User-agent: |
Mutt/1.0.1i |
OK, now there are two contradictionary opinions. Let's fight it out:
:-)
As I see it, the whole discussion starts at the point of "closedness"
groups. In case the English term I'm using is wrong, here is what I
mean:
You have a set and a binary operation on that set. "closedness" means
that by using the operation on any two values from the set gives you a
value from the set again. Therefore:
(INTEGER,plus) is closed
(RATIONAL,plus) is closed
(RATIONAL\{0},divide) is closed
(INTEGER\{0},divide) is *not* closed
that, of course, gives the impression that you can do more with
rationals than you can do with integers.
But as I said: closedness has to be dropped for the subtyping concept
to work. It does not matter at all, whether you talk of "subsets" or
"substitutionability". Those two are the same!
Think of a machine that only swallows RATIONAL values. Feed it a
INTEGER and it won't even notice it.
Now the other way around: a machine that is constructed to eat
INTEGERS. Feed it 1/2 and it will die horribly!
Or in sather terms:
class ARRAY{SOMETYPE} is
aval(index: $INTEGER): SOMETYPE is ... end;
end;
If you really had $RATIONAL < $INTEGER, it would be correct to ask for
myarray[1/2];
That can't be correct!
Ciao,
Nobbi
On Thu, Oct 05, 2000 at 07:36:58PM +0000, Matt Kennel wrote:
> On Wed, 4 Oct 2000 09:17:15 +0200, Norbert Nemec <address@hidden> wrote:
> :After all, that's a conceptual problem in the modelling process: In
> :fact, $RATIONAL cannot be a subtype of $INTEGER.
>
> :It should rather be the
> :other way around, since "subtype" is a kind of an equivalent to
> :"subset".
>
> I think that notion is wrong.
>
> Instead subtype reflects functional properties, and a rational number
> can be substituted in all places that an integer is desired. There is
> an equivalent rational for all integers, and a zero element, and a
> group operation that works fine.
>
> : $INTEGER being a subtype of $RATIONAL would mean: I can use
> :an $INTEGER everytime a $RATIONAL is needed. And that really is true.
>
> But it isn't.
>
> :Of course, after a division, I might not get a $INTEGER as result, but
> :that's another matter.
>
> I see this as exactly the reason why it can't be a subtype.
>
> Rationals can do everything integers can, but integers can't do everything
> rationals can.
>
> :In fact, $INTEGER does even have additional properties like a possible
> : next: SAME is ... end;
> :method.
>
> If you put that property in $INTEGER than maybe rationals wouldn't be
> substitutable, but even still there are enumerations, nonobvious as
> they may be, of rationals.
>
> :The one essential property of groups and fields - how is it called in
> :English? "closedness" would be the translation from German - simply
> :cannot be modelled without genericity. In subtyping, meaning the look
> :at only a subset of the original, the "closedness" simply is lost, and
> :has to be "defined" newly. Correctly it would have to be:
> :
> :class $GROUP{T} ...
> :
> :class $FIELD{T} < $GROUP{T} ...
> :
> :class $RATIONAL < $FIELD{$RATIONAL} ...
> :
> :class $INTEGER < $RATIONAL, $GROUP{$INTEGER} ...
> :
> :Of course, now you have $INTEGER < $FIELD{$RATIONAL}, but that simply
> :sais: integers are a sub*set* of the field of rationals, which is fully
> :correct.
>
> I don't think that subtyping in programming language reflects subset
> relationships of elements but functional substitutability.
>
> --
> * Matthew B. Kennel/Institute for Nonlinear Science, UCSD
> *
> * "To chill, or to pop a cap in my dome, whoomp! there it is."
> * Hamlet, Fresh Prince of Denmark.
--
-- ______________________________________________________
-- JESUS CHRIST IS LORD!
-- To Him, even that machine here has to obey...
--
-- _________________________________Norbert "Nobbi" Nemec
-- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany
-- eMail: <address@hidden> Tel: +49-(0)-9131-204180