Re: What databases have taught me
Date: Fri, 30 Jun 2006 21:16:30 +0200
Message-ID: <1kqyashmr9sgw.mqcfk016ctkp$.dlg_at_40tude.net>
On 30 Jun 2006 10:49:39 -0700, Marshall 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.
- Why parsing need to be bottom-up?
- What is the type of 1?
- The type of an expression (if any) is Expression.
- The type of a result of an expression is determined by the expression and the context of.
- 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:
- Whether int and float are related types.
- 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]
- The context of the expression
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Fri Jun 30 2006 - 21:16:30 CEST