← Back to context

Comment by roetlich

1 month ago

I think you need to re-read some of the comments you are replying to. There is a 64 bit int type: https://ocaml.org/manual/5.3/api/Int64.html You can use all 64 bits. There are also other int types, with different amounts of bits. For example, 32 bit: https://ocaml.org/manual/5.3/api/Int32.html No one will stop you. You can use all the bits you want. Just use the specific int type you want.

ravi-delia explained that the fact is that an OCaml int is different than either Int32 or Int64 because an 'int' sacrifices one of its bits to the OCaml runtime. Int32 or Int64 are treated completely differently and are library defintions, bolted onto the OCaml runtime.

That is a runtime system not suitable for systems-level programming.

My C experience gave me a fundamental misunderstanding because there, an int is always derived from either an 32- or 64-bit int, depending on architecture.

OCaml is architected differently. I imagine the purpose was to keep the programs mostly working the same across processor architecture sizes.

I imagine this fundamental difference between OCaml's native int and these more specific Ints is why there are open issues in the libray that I"m sure the int does not.

Regardless, no one should be using OCaml for systems-level programming.

Thanks for helping me get to the heart of the issue.

  • The situation is that OCaml is giving you all the options:

    (a) int has 31 bits in 32-bit architectures and 63 in 64-bit architectures (which speed up some operations)

    (b) the standard library also provides Int32 and Int64 modules, which support platform-independent operations on 32- and 64-bit signed integers.

    In other words: int is different but you always have standard Int32 and Int64 in case you need them.

    It seems therefore that the use for system-level programming should not be decided for this (although the fact that it is a garbage collected language can be important depending on the case, note that still its garbage collector has been proved one of the fastest in the comparisons and evaluations done by the Koka language team of developers).