Re: What databases have taught me

From: Marshall <>
Date: 30 Jun 2006 10:49:39 -0700
Message-ID: <>

Dmitry A. Kazakov wrote:
> On 30 Jun 2006 09:39:29 -0700, Marshall wrote:
> > Dmitry A. Kazakov wrote:
> >> On 30 Jun 2006 08:39:09 -0700, Marshall wrote:
> >>>>
> >>>> Side note: in a strongly typed language "extension" of an operation can be
> >>>> accomplished only through an "extension" of the type (actually a class of).
> >>>> This happens by adding a new type to the class, so that the operation
> >>>> extension be defined on that new type.
> >>>
> >>> I believe you are descring OO here, yes?
> >>
> >> Actually any typed system with user-defined relations on types, I don't
> >> think that it is any specific to OO. Nothing prevents RM from allowing
> >> polymorphic values in tuples. Also tuples themselves could be made
> >> polymorphic as well (to support mixed logics, for example, or to attach
> >> some constraints etc).
> >
> > Mmmm, what I was trying to point out is that it is a somewhat
> > OOish idea to consider functions on a type as part of the
> > definition of that type.
> >
> > Given a set A, and a set B.
> > Given a function f: A -> B
> >
> > We would not *necessarily* consider f as part of the definition of A.
> Absolutely. f is a part of definition of both.

Well, certainly there are some definitions that work that way, and certainly there are some that don't. I would describe those that do as being at least vaguely OO. I never saw a math textbook that defined it that way, for example.

> type <-> function is a relation. "Member" function is rubbish. BTW, when I
> talk about multiple dispatch I do include results of functions. So, say
> + : A x B -> C
> is triple dispatching. It is an operation of types A, B, C.

Oh my goodness, that raises a whole host of problems! You can't effectively dispatch on the right side of the arrow, because that's the type of the result expression.

For example, if you define both
+: int, int -> int
+: int, int -> float

then what is the type of "1+1"? It could be either int or float. You *don't* want to be in a situation where you can't assign a type to an expression; it introduces cascading ambiguity.

Marshall Received on Fri Jun 30 2006 - 19:49:39 CEST

Original text of this message