4 ms·

The usual int type is 63 bits. You can get a full 64 bit int, it just isn't the default.

MrMcCall 2y ago
The docs say, "one bit is reserved for the OCaml runtime", so doesn't that mean that one of the bits (likely the high bit) are unavailable for the programmer's use? I mean, I understand "reserved" to mean either "you can't depend upon it if you use it", or "it will break the runtime if you use it".
- lapinot 2y ago
  https://ocaml.org/manual/5.3/api/Int64.html https://ocaml.org/manual/5.3/api/Int64.html
  - MrMcCall 2y ago
    I see, now. From that doc: > Performance notice: values of type int64 occupy more memory space than values of type int I just couldn't even imagine that a 64-bit int would require MORE memory than an int that is one bit less (or 33 bits less if on a 32-bit architecture). It really makes absolutely no sense discussing OCaml as a possible systems-level programming language.
    - MrMcCall 2y ago
      Sorry, I should have said that an Int64 shouldn't take more memory on a 64-bit system where the default int is 63 bits, because of the "reserved bit". It was early this morning.
      - mbac32768 2y ago
        bruh, it's just saying single scalar Int64 types are boxed. This is totally normal thing that happens in garbage collected languages. There's no semantic loss. OCaml does this 63-bit hack to make integers fast in the statistically common case where people don't count to 2^64 with them. The top bit is reserved to tell the GC whether it manages the lifetime of that value or not. For interoperating with binary interfaces you can just say `open Int64` at the top of your file and get semantic compatibility. The largest industrial user of OCaml is quant finance shop that binds all kinds of kernel level drivers with it. (and yes, 64-bit non-boxed array types exist as well if you're worried about the boxing overhead)
- ravi-delia 2y ago
  So the "one bit" you refer to is what makes the standard int 63 bits rather than 64. If you could do things with it it would indeed break the runtime- that's what tells it that you're working with an int rather than a pointer. But full, real, 64-bit integers are available, in the base language, same goes for 32.
  - MrMcCall 2y ago
    And that means that the OCaml runtime is not compatible with systems-level programming. If something is "available", it should mean that it can be used to its full capacity. One of those bits are definitely not available.
    - roetlich 2y 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 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 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.
      - MrMcCall 2y ago
        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 docs say, "one bit is reserved for the OCaml runtime", so doesn't that mean that one of the bits (likely the high bit) are unavailable for the programmer's use? I mean, I understand "reserved" to mean either "you can't depend upon it if you use it", or "it will break the runtime if you use it".

lapinot 2y ago
https://ocaml.org/manual/5.3/api/Int64.html https://ocaml.org/manual/5.3/api/Int64.html
- MrMcCall 2y ago
  I see, now. From that doc: > Performance notice: values of type int64 occupy more memory space than values of type int I just couldn't even imagine that a 64-bit int would require MORE memory than an int that is one bit less (or 33 bits less if on a 32-bit architecture). It really makes absolutely no sense discussing OCaml as a possible systems-level programming language.
  - MrMcCall 2y ago
    Sorry, I should have said that an Int64 shouldn't take more memory on a 64-bit system where the default int is 63 bits, because of the "reserved bit". It was early this morning.
    - mbac32768 2y ago
      bruh, it's just saying single scalar Int64 types are boxed. This is totally normal thing that happens in garbage collected languages. There's no semantic loss. OCaml does this 63-bit hack to make integers fast in the statistically common case where people don't count to 2^64 with them. The top bit is reserved to tell the GC whether it manages the lifetime of that value or not. For interoperating with binary interfaces you can just say `open Int64` at the top of your file and get semantic compatibility. The largest industrial user of OCaml is quant finance shop that binds all kinds of kernel level drivers with it. (and yes, 64-bit non-boxed array types exist as well if you're worried about the boxing overhead)
ravi-delia 2y ago
So the "one bit" you refer to is what makes the standard int 63 bits rather than 64. If you could do things with it it would indeed break the runtime- that's what tells it that you're working with an int rather than a pointer. But full, real, 64-bit integers are available, in the base language, same goes for 32.
- MrMcCall 2y ago
  And that means that the OCaml runtime is not compatible with systems-level programming. If something is "available", it should mean that it can be used to its full capacity. One of those bits are definitely not available.
  - roetlich 2y 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 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 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.
    - MrMcCall 2y ago
      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.