[antisemiotic]

In both SML and OCaml writing a function that's polymorphic over numeric types is a huge pain in the ass, so I'm not sure it's a good choice for numeric programming. (Unless you count Haskell as a member of the ML family?) Though it could be that generics aren't that important here, and I'm just a weirdo who liked to do things like implementing a dual number type to get forward-mode automatic differentiation of standard functions for free...

[ernst_klim]

> In both SML and OCaml writing a function that's polymorphic over numeric types is a huge pain in the ass, so I'm not sure it's a good choice for numeric programming.

What? In numeric programming we usually want the opposite, to write a function for specific type, and to make it run fast.

Also, in OCaml you can simply make your computation a parametric module of some algebraic structure, something like

    module type Ring = sig
       type t
       val zero : t
       val one : t
       val (+) : t -> t -> t
       ...
    end

    module Numeric_staff (N : Ring) = struct
       ...

And have a completely static numeric computation without any dynamic dispatch. That's resembling C++'s templates.

You also can use classes if you want dynamic dispatch

    let (+) x y = x#add y

[higherkinded]

Haskell is its direct descendant, so of course it counts. It has all the traits required to be called that, and I'm implicitly talking towards it in the initial comment while still respecting the family. And for what I know, OCaml has generics, so I'm not exactly sure what do you mean here.

[antisemiotic]

I haven't ever written any OCaml, but I thought it has separate operators for ints and floats. I've written some SML and it has some special hacks to allow overloading on built-in operators. While I do understand that ML style modules are theoretically more powerful than Haskell's typeclasses, they always struck me as much clunkier for everyday use (that's why I personally consider ML family and Haskell family as separate - the approach to ad-hoc polymorphism is an important difference in my opinion)

[ernst_klim]

> they always struck me as much clunkier for everyday use

They are simply explicit. What's so clunky about modular implicits, for example?

Personally, I prefer explicit modules and hate typeclasses, because I can't look at the code and say if this operation is a primitive operator or some dynamically dispatched class method.

Besides, modules are way more powerful, and have a way broader use. They can encapsulate state, types, can be parametric etc.