Difference from Native OCaml
In OCaml, the C FFI allows the user to define a custom data type and customize
caml_hash behavior, etc. This is not available in our backend (since we have no C FFI).
In general, only use physical equality as an optimization technique; don't rely on its correctness, since it is tightly coupled with the runtime.
OCaml’s weak map is not available in BuckleScript. The weak pointer is replaced by a strict pointer.
int64in BuckleScript have the exact same semantics as OCaml.
intin BuckleScript is the same as
int32while in OCaml it’s platform dependent.
Nativeint.div a bwill be translated into
a / b | 0.
Nativeint.shift_right_logical x 0 is different from
Int32.shift_right_local x 0. The former is literally translated into
x >>> 0 (translated into an unsigned int), while the latter is
x | 0.
The Printf.print implementation in BuckleScript requires a newline (
\n) to trigger the printing. This behavior is not consistent with the buffered behavior of native OCaml. The only potential problem we foresee is that if the program terminates with no newline character, the text will never be printed.
We do our best to mimic the native compiler, but we have no guarantee and there are differences.
BuckleScript uses the same algorithm as native OCaml, but the output is different due to the runtime representation of int/int64/int32 and float.
Not supported yet.
Command line arguments are always empty. This might be fixed in the future.
Sys.max_string_length will be the same as
max_int, but it might be respected.
Because of the JS environment limitation,
Pervasives.stdin is not supported but both