I totally agree that expressions manipulating Int64 and Int32 quickly become
illegible, however I don't agree with your suggestions...

> Int64.add (Int64.mul (Int64.add a b) b) c;;
>
> especially when you try to avoid exceeding a limit of 79 characters in
> line. 

OT: May I politely suggest that perhaps your coding standards could do with
updating to mitigate part of this. Unless you're still on an 80x25 character
terminal limiting yourself to 79 characters per line is pretty archaic. We
use 150 character max line limit (and print in landscape if necessary)
because every display we work on has a resolution of at least 1280x1024.

> The best solutions to those problem would be in my opinion to add
> something like this to standard library (to new module):
>
> let ( +^^ ) a b = Int64.add a b
<snip>
>
> let ( +^ ) a b = Int32.add a b
<snip>

My problem with this, as someone who writes a lot of OCaml but uses Int64
and Int32 rarely, is that these operators aren't clearly anything to do with
Int64 or Int32 in terms of their "names" (symbols). Defining funny strings
of symbols to get around the (intentional) limitations of not having
operator overloading is IMHO not something that should be in the standard
library. If you're writing code that uses the operations so frequently that
clarity requires aliases then your code will be much more readable if you
have:

(* other, non-Int64/32 code *)

let ( +^^ ) a b = ...
and ( -^^ ) a b = ...
...
in
  (*
   * A block of code of reasonable length that makes extremely dense use of
   * the above operators.
   *)

(* Perhaps more non-Int64/32 code *)

That said, you could do it your way and my way with the aid of pa_openin
which allows you to open a module just within a block of code which would
save writing out the operators every time - for *your* code.

cout << "Adding lots of strange-looking operators (even in sub-modules \
that would need to be opened) to the StdLib is one step down the slippery \
slope to C(++) operator hell..."

Just my two pennyworth...


David