Re: [Caml-list] Observations on OCaml vs. Haskell

[Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>]

The answers are clear enough for your first two questions, so I just
add some details to the 3rd.

From: John Goerzen <jgoerzen@complete.org>
> 3. The Num typeclass
> 
> I've written several functions that can work with a "number-like" type.  
> I don't really care if I get an integer, Int32, Int64, float, or what.  
> But since these are all different types in OCaml, I am forced to care, 
> right down to using +, +., or Int64.add to perform basic arithmetic.  
> The Num typeclass in Haskell neatly solves that whole problem; I could 
> take a Num, use a unified set of operators, and produce the appropriate 
> result.

This is again a problem of performance. An arithmetic operation on a
normal int when the compiler doesn't know that this is an int will be
several orders of magnitude slower than when it knows this is an int.
This is actually worse than boxing/unboxing: you have to dispatch
according to the runtime type of the data.

Simple overloading would avoid this cost (it is resolved at
compile time), but it doesn't provide what you ask for: real
polymorphism.

If you don't care about performance, there are several ways you can
obtain such polymorphism in ocaml:

* Functors. There are already modules in the compiler for Int32, Int64
  and Nativeint, you will just have to write a common signature (they
  all have the same operations), and similar modules for Int and
  Float. Then you can parameterize your whole algorithm on the type to
  be used. Then, if you can find a defunctorializer (I believe there
  is one around), you can recover unfettered performance.

* Objects. It may be funnier, as you can make things more dynamic. But
  there are no optimizations available.

* Sum types. Define a big sum
      type num = Int of int | Float of float | ...
  and do all compuations with automatic conversions. This shouldn't be
  worse than polymorphism, and you can combine different types.

Of course, that leaves us with the problem of syntax.
If you redefine the standard operators to use your new numbers, then
you're in trouble when using normal ints.
And you don't even have such an option for literal numers, but they
are not too bad with a prefix operator.

Jacques

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners