3 ms·

I'm still not sure I follow what the gain is here? I get that it makes it possible to differentiate between an int and pointer, but why is that actually importa

I'm still not sure I follow what the gain is here? I get that it makes it possible to differentiate between an int and pointer, but why is that actually important. The compiler already has type information right? And would know whether a value is a pointer or int?

rwmj 3y ago
An immediate reason is that some variants can be either ints or boxed. eg: type t = One (* represented as int 0 (0b01) *) | Two (* represented as int 1 (0b11) *) | Pair of t * t (* boxed (ie. pointer) *) The representation used by OCaml is quite subtle. There's a distinction between the very rich types known at compile time which are almost all erased, and the little bit of information that is needed at runtime mainly by the garbage collector. Here are some links to how it all works: https://dev.realworldocaml.org/runtime-memory-layout.html https://dev.realworldocaml.org/runtime-memory-layout.html https://rwmj.wordpress.com/2009/08/04/ocaml-internals/ https://rwmj.wordpress.com/2009/08/04/ocaml-internals/ https://web.archive.org/web/20210412024831/http://caml.inria.fr/pub/ml-archives/caml-list/2002/08/e109df224ff0150b302033e2002dbf87.en.html https://web.archive.org/web/20210412024831/http://caml.inria...
- thinkharderdev 3y ago
  Ah yes, I wasn't thinking about the gc. That makes more sense now. Thanks!
Dylan16807 3y ago
The type of a variable can be "x or y or z", so no the compiler won't always know that.
- gpderetta 3y ago
  That's an union type, right? I would expect it to have a separate discriminant field if there are no available bits in the object representation itself.
  - a1369209993 3y ago
    The catch there is "separate" - if the object representation is one machine word, you really do not want to have to increase that by a factor of two to store one additional bit of information, and implementors will generally try hard to avoid that if at all possible.
- deleted 3y ago
  [deleted]
Sharlin 3y ago
Looks like it’s an optimization to avoid boxing integers that can be stored inline. So two runtime representations for the same type.

rwmj 3y ago

An immediate reason is that some variants can be either ints or boxed. eg: type t = One (* represented as int 0 (0b01) *) | Two (* represented as int 1 (0b11) *) | Pair of t * t (* boxed (ie. pointer) *) The representation used by OCaml is quite subtle. There's a distinction between the very rich types known at compile time which are almost all erased, and the little bit of information that is needed at runtime mainly by the garbage collector. Here are some links to how it all works: https://dev.realworldocaml.org/runtime-memory-layout.html https://dev.realworldocaml.org/runtime-memory-layout.html https://rwmj.wordpress.com/2009/08/04/ocaml-internals/ https://rwmj.wordpress.com/2009/08/04/ocaml-internals/ https://web.archive.org/web/20210412024831/http://caml.inria.fr/pub/ml-archives/caml-list/2002/08/e109df224ff0150b302033e2002dbf87.en.html https://web.archive.org/web/20210412024831/http://caml.inria...

thinkharderdev 3y ago
Ah yes, I wasn't thinking about the gc. That makes more sense now. Thanks!

Dylan16807 3y ago

The type of a variable can be "x or y or z", so no the compiler won't always know that.

gpderetta 3y ago
That's an union type, right? I would expect it to have a separate discriminant field if there are no available bits in the object representation itself.
- a1369209993 3y ago
  The catch there is "separate" - if the object representation is one machine word, you really do not want to have to increase that by a factor of two to store one additional bit of information, and implementors will generally try hard to avoid that if at all possible.
deleted 3y ago
[deleted]

Sharlin 3y ago

Looks like it’s an optimization to avoid boxing integers that can be stored inline. So two runtime representations for the same type.