Re: What databases have taught me

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Fri, 30 Jun 2006 21:16:30 +0200
Message-ID: <1kqyashmr9sgw.mqcfk016ctkp$.dlg@40tude.net>

On 30 Jun 2006 10:49:39 -0700, Marshall wrote:

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

Why? Mathematics is full of such stuff. Field is a not a field without +. Types aren't sets of values. They are structures like: ring, field etc.  

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

C is a brain cancer. Alas, that Dijkstra wrote only about Basic! (:-)) There are so many misconceptions in one single phrase, that I don't know where to start from.

1. Why parsing need to be bottom-up?
2. What is the type of 1?
3. The type of an expression (if any) is Expression.
4. The type of a result of an expression is determined by the expression and the context of.
5. Of course you define both if int and float are in the same class. You *must* define both. And also (assuming int was derived from float):

+: int x float -> int
+: float x int -> int
+: float x float -> int
+: int x float -> float
+: float x int -> float

(it explodes geometrically)

> You *don't* want to be in a situation where you can't assign
> a type to an expression; it introduces cascading ambiguity.

See 3. As for the result of, in a typed language is *always* defined. Because each object has *a* type. As for your example, nothing can be said, as long as it is unknown:

1. Whether int and float are related types.
2. The function 1 [note, literals are parameterless functions 1:->? For example it could be two overloaded 1's: 1:->int and 1:->float, but better not to do such things]
3. The context of the expression

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Received on Fri Jun 30 2006 - 14:16:30 CDT