Re: Fwd: [Caml-list] Polymorphic Variants

[Jon Harrop <jon@ffconsultancy.com>]

On Thursday 18 January 2007 16:23, Tom wrote:
> No... i rather thought it that way:
>      x is anything
>      x * x is either int or float, so x is either int or float
>      x * x + x * x is either int or float, so the two (x * x) are either
> both int or both float
>      sqrt accepts a float argument, so x * x + x * x must be float, so (x *
> x) must be float, so x must be float.

Much better. Except I want + to work on int, float, float32, 'a^n (static 
vectors), 'a^n^m (static matrices), 'a array, 'a list, 'a set. Not only that, 
I want + and * to work on two values of different types: date+time, 
float*vector and so on.

Hell, I want to overload 0 to mean 0, 0., 0. + 0.i, zero vector and the zero 
matrix. Of course, the zero matrix has arbitrary dimensionalities that could 
be static, so my type now contains variables for those.

Now, where your type inferencer had a simple type expression or atom (int or 
float), it can have expressions of mutually-recursive sets of type 
expressions.

You see how things will get more complicated to define correctly, slower to 
compile and much harder to comprehend when things go wrong? You've opened a 
whole can of worms. Some of those worms look tasty but you either eat them 
all or you put them all back.

> > You could even add a float literal:
> >
> > x +. 0.
>
> and have it optimized away

No, because x+0=x is not true for all floats:

# -0. +. 0.;;
- : float = 0.

> You see, I am not against OCaml. No! I love it. And I am not trying to
> change it. You seem to be a priori against my ideas, just because they are
> not what is generally accepted.

Not at all. They are very good ideas on the surface. The problem is what costs 
lay hidden beneath the surface in an implementation of such a language.

> All I want to do is write my own language, 
> both for the sake of writing one (they say it's good practice) and for the
> sake of correcting things that I have found bother me when I program OCaml.
> As pointed out a number of times, you should design a language for
> yourself, not for others, not for the "general public" [1].

Ok.

> So what I want 
> is something that will enable me to program in a fast, yet efficient
> manner, and to be able to express many things as naturally as possible.
> Therefore, most of the features I suggested are not "evil" or "mean", they
> are just my solutions to what I think are the most common problems -
> actually, one biggest problem: too much typing.

Then I think you need to choose bigger examples in order to weigh the 
reduction in code size that you've seen with the increase in code size due to 
type annotations.

> No, actually, the nominal 
> subtyping of records is because it's faster than structural subtyping of
> objects, as implemented by OCaml.

That's a good idea. I'd like to have vec2 and vec3 records that reused x and y 
field names.

> If anyone has any idea, how to make 
> structural subtyping faster, I would love to incorporate it.

Right. I think structural subtyping is a good complement to the rest of 
OCaml's type system.

> > What happens at code boundaries? e.g. to compile a DLL, the compiler must
> > generate all possible permutation of type variables for every function.
> > Then
> > you end up with a compiler that's 2,000x slower than OCaml's, like the
> > Stalin
> > scheme compiler.
>
> In addition to what I have written in the previous remark, I think you are
> overly concerned with performance only.

I am, yes. OCaml's designers were too, I think.

> It's great you think about many 
> things, but these things have quite simple answers. Either, one could write
> an incremental compiler (similar to the way OCaml provides separate
> compilation, but somehow more refined is what I have in mind), or write
> interfaces - again what OCaml does (to optimise say, the min function (let
> min (x: int) y = if x > y then y else x) so that it is faster) - it's just
> that what you would actually need to do is DELETE interfaces, because the
> compiler would infer the whole interface for you, and you would just delete
> the entries you don't want to have in it.

Good idea. Not having to repeat types in .mli files would be an improvement, 
IMHO.

> All in all, I believe that optimizations (compile-time evaluation (and
> don't say I forgot that some functions have side effects)), incremental
> compilation and a smart and powerful IDE, along with OCaml's already
> existent debugger and profiler should keep one from being stopped by
> implementation issues. Idea, ideas, ideas are important, ideas are what
> matters.

Absolutely. I would welcome a decent OCaml IDE. I've even considered writing 
one a few times, but you'd need a good GPU to run mine. ;-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists