Fwd: [Caml-list] Polymorphic Variants

[Tom <tom.primozic@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4655 bytes --]

---------- 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 18/01/07, Jon Harrop <jon@ffconsultancy.com> wrote:

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

[1] http://www.paulgraham.com/langdes.html (2. Design for Yourself and Your
Friends. )


By the way, do you think I can send this message to others too? (I think it
significantly clarifies my position)

- Tom

[-- Attachment #2: Type: text/html, Size: 6774 bytes --]