Re: What databases have taught me
Date: 30 Jun 2006 12:49:36 -0700
Dmitry A. Kazakov wrote:
> 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 +.
Field is a type. Natural number is also a type, and + is not required
for that type, but it is certainly useful. So I have to disagree that
the only way to look at it.
> >> 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! (:-))
Why on earth are you bringing C into this discussion? How is it relevant?
> 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?
"bottom-up" is not the question; the question is context-free vs.
The disadvantages of context-sensitivity are well documented, and enough of
a reason for most programming languages to be context-free.
In many languages, and in my hypothetical example language, integer.
This is equivalent to saying that only untyped languages exist. I
reject that claim, and in fact I am relatively uninterested in
that lack a static type system, although of course they exist.
> 4. The type of a result of an expression is determined by the expression
> and the context of.
That's certainly a possibility, but not the only possibility, and in
one that has been widely rejected by PLT as having many disadvantages.
I also note that your item 4 contradicts your item 3.
> 5. Of course you define both if int and float are in the same class. You
> *must* define both.
No, that is certainly not true. I don't know of any languages that do
I do not so assume.
> +: 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.
This doesn't say anything about whether your idea of dispatching on return type is feasible or not in a statically typed, context-free language, and in fact it isn't. It introduces ambiguity in the type of function invocation expressions. Being able to uniquely assign types to all terms is one of the most important properties of statically typed languages.
I also note the above confuses static concerns, specifically the type of an expression, with dynamic concerns, namely the runtime type of an object.
> As for your example, nothing can be said,
> as long as it is unknown:
> 1. Whether int and float are related types.
Doesn't matter. If int <: float, then my example is ambiguously typed. If int is distinct from float, then my example expression is ambiguously typed.
> 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]
Why better not to do such things? Why is it okay to overload the return
of parametric functions, but "better not to" overload parameterless functions?
> 3. The context of the expression
Only relevant for context-sensitive languages.
Marshall Received on Fri Jun 30 2006 - 21:49:36 CEST