Re: extended operator classes vs. type interfaces

Robert Haas  wrote:
> Given a type T, I think we'd like to be able to define a type U as
> "the natural type to be added to or subtracted from T".  As Jeff
> pointed out to me, this is not necessarily the same as the
> underlying type.  For example, if T is a timestamp, U is an
> interval; if T is a numeric, U is also a numeric; if T is a cidr,
> U is an integer. Then we'd like to define a canonical addition
> operator and a canonical subtraction operator.
As it is de rigueur for someone to escalate the proposed complexity
of an idea by at least one order of magnitude, and everyone else has
fallen down on this one:  ;-)
I've often thought that if we rework the type system, it would be
very nice to support a concept of hierarchy.  If you could
"subclass" money to have a subclass like assessable, which in turn
has subclasses of fine, fee, restitution, etc. you could then
automatically do anything with a subclass which you could do with
the superclass, and support such things as treating the sum of
various classes as the lowest common subclass.  It seems like this
sort of approach, if done right, might allow some easier way to
establish sensible operations between types (like distance / speed =
time or speed * time = distance).
Just a thought....
-Kevin