---------- Forwarded message ----------
From: Tom <tom.primozic@gmail.com>
Date: 18-Jan-2007 13:07
Subject: Re: [Caml-list] Polymorphic Variants
To: Jon Harrop <jon@ffconsultancy.com>
On Wednesday 17 January 2007 23:07, you wrote:
> 3 solutions:
> * sqrt has type of float -> float and the compiler infers float arguments
Type inference starts at the leaf subexpressions. In the absence of other type
information, it gets to x*x and infers x to be the default type parameter of
+ and then fails when it gets to sqrt of an int.
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.
> * you write +. and *. (at least once) (those operators could be still
> available, don't you think so?)
Yes. Then you have complicated the language without improving upon OCaml.
Hm... well, I must say that I agree. Actually, I am against this option (for purposes other that compatibility with original OCaml)
You could even add a float literal:
x +. 0.
and have it optimized away
> And the records could be
> optimised so that type information is only added when it is needed by the
> programm.
Then you acquire the poor optimisability of Lisp, where you are forced to
plough through reams of optimisation-related compiler warnings in order to
find exactly where you must annotate the code to recover the lost
performance.
Well... I guess it's quite simple. If it's only one record, than optimise it. If it has "subrecords" (=subtypes), than don't.
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. 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]. 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. No, actually, the nominal subtyping of records is because it's faster than structural subtyping of objects, as implemented by OCaml. If anyone has any idea, how to make structural subtyping faster, I would love to incorporate it.
> * let the compiler overload your function ( length : (int * int) ->
> float; length : (float * float) -> float) and then drop the "int" one as
> you never ever used it in your code.
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. 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.
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.
By the way, do you think I can send this message to others too? (I think it significantly clarifies my position)
- Tom