Comment author: pcouderc

It works in Haskell because literals have type Number, which is usable thanks to the typeclass Num (https://www.haskell.org/onlinereport/basic.html#numbers) and the instances associated (Integer, Float, etc). For example, 42 has type (Num a) => a: it is not an integer, neither a float, simply a numeric literal whose exact type will be instantiated at will depending on the context, using the correct typeclass instance.

In OCaml, it would need to change the typing of constants to a "numerical" type, and allow modules to redefine this type by providing the necessary functions like in Haskell, and use a functor to "produce" this new literal type. I am not sure it is doable, but I might be wrong!

If I'm not mistaken, in Coq literals can be defined as Peano Numbers (type n = Zero | Succ of n), but it wouldn't be really efficient (or would need some kind of preprocessing). We could define literals as some kind of "operators" that are redefinable.

As for arrays syntax, the newly introduced syntax for Bigarray assignment (#69) can be extended to support array-like operators, I guess:
let ( [|,..,|] ) = ...

In both cases, it would be useful but probably not possible for the former.

Comment author: @mmottl

@psouderc: it would, of course, be even nicer if Haskell-style type classes could be successfully integrated with the OCaml type system, but I wouldn't hold my breath on that one. AFAIK, Haskell also just rewrites the literal "42" to "fromInteger 42", where the latter "42" is the actual value of type "Integer". It's the implicitly added call to "fromInteger" of type "Num a => Integer -> a" that introduces the type class.

The difference to Haskell would be that it's not type inference that would determine what function to call for the coercion, it would merely be the current binding of "of_???_literal". The type system would not require any change whatsoever.

Comment author: @mshinwell

Even with modular implicits it seems as if implicit conversions of literals wouldn't be implemented, lest it cause confusion. The particular example of "Complex.(3 + x)" could be implemented using modular implicits (to define a special "+" operator), although one would be wise to take note from C++ as to what happens when such ad-hoc overloading is omnipresent.

Any objections to closing this PR?

Comment author: @mmottl

What kind of confusion would you be concerned about? I agree that type-based strategies, elegant as they may be, can sometimes be difficult to interpret by a human. I haven't looked into modular implicits for that purpose yet. But at least in the classic module context it should always be easy to determine where a coercion function is coming from.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.