Earlier quoted context omitted.
Anonymous labeled structs and enums are some of my top wished-for features in programming languages! For instance, in Rust you can define labelled and unlabelled (i.e. tuple) structs struct Foo(i32, i32); struct Bar{sum: i32, product: i32} But you can only e.g. return from functions an anonymous tuple, not an anonymous labelled struct fn can() -> (i32, i32) fn cant() -> {sum: i32, product: i32}
Hmm. Let me first check that I've understood what you care about struct First(this: i8, that: i64) struct Second(this: i8, that: i8) struct Third(that: i64, this: i8) struct Fourth(this: i8, that: i64) struct Fifth(some: i8, other: i64) You want First and Fourth as the same type, but Second and Third are different - how about Fifth? I see that this is different from Rust's existing product types, in which First and F…
OxCaml - a set of extensions to the OCaml programming language.
21–30 of 128 posts
Re: OxCaml - a set of extensions to the OCaml programming language.
#22The first feature that originated in this fork to be upstreamed is labeled tuples, which will be in OCaml 5.4: https://github.com/ocaml/ocaml/pull/13498 https://discuss.ocaml.org/t/first-alpha-release-of-ocaml-5-4...
- https://www.youtube.com/watch?v=WM7ZVne8eQE
- https://tyconmismatch.com/papers/ml2024_labeled_tuples.pdf
Re: OxCaml - a set of extensions to the OCaml programming language.
#23I wasn't aware that this fork supported SIMD! Between this, unboxed types and the local mode with explicit stack allocation, OxCaml almost entirely replaces my past interest in F#; this could actually become usable for gamedev and similar consumer scenarios if it also supported Windows.
Yeah, this would be great! Currently only 128-bit SSE/NEON is working but AVX is coming very soon. There's also nothing blocking Windows, but it will require some work. (I added the SIMD support in OxCaml)
Re: OxCaml - a set of extensions to the OCaml programming language.
#24Earlier quoted context omitted.
Rust will probably become usable with custom tracing GCs (which is helpful if you're dealing with general graph-like data but still want the highest performance as far as practical) way before this effort reaches genuine feature parity with Rust. Not seeing much of a point in this, unless they perhaps intend to focus on the lowest-hanging fruit and have big O(x)Caml codebases that they care about.
> Not seeing much of a point in this OCaml is a good language and these extensions are very welcome to existing OCaml programmers and programs, as well as many of the other extensions Jane Street has added. I don't understand what you mean here.
> ...I don't understand what you mean here.
Yeah it seems there was a mistake there, it looks like my comment got cut off while you were reading it. Try reloading the page maybe?
Re: OxCaml - a set of extensions to the OCaml programming language.
#25The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…
Re: OxCaml - a set of extensions to the OCaml programming language.
#26Earlier quoted context omitted.
Yeah, this would be great! Currently only 128-bit SSE/NEON is working but AVX is coming very soon. There's also nothing blocking Windows, but it will require some work. (I added the SIMD support in OxCaml)
FWIW, the "Get OxCaml" page actually says that SIMD on ARM isn't supported yet. If it actually works it would be worth removing that from the known issues list https://oxcaml.org/get-oxcaml/
Re: OxCaml - a set of extensions to the OCaml programming language.
#27I wasn't aware that this fork supported SIMD! Between this, unboxed types and the local mode with explicit stack allocation, OxCaml almost entirely replaces my past interest in F#; this could actually become usable for gamedev and similar consumer scenarios if it also supported Windows.
Yeah, this would be great! Currently only 128-bit SSE/NEON is working but AVX is coming very soon. There's also nothing blocking Windows, but it will require some work. (I added the SIMD support in OxCaml)
Re: OxCaml - a set of extensions to the OCaml programming language.
#28The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…
Haven't looked at the link, but I think for a scenario like trading where there are market open and close times, you can just disable the GC, and restart the program after market close.
Re: OxCaml - a set of extensions to the OCaml programming language.
#29Earlier quoted context omitted.
> Not seeing much of a point in this OCaml is a good language and these extensions are very welcome to existing OCaml programmers and programs, as well as many of the other extensions Jane Street has added. I don't understand what you mean here.
> > Not seeing much of a point in this > ...I don't understand what you mean here. Yeah it seems there was a mistake there, it looks like my comment got cut off while you were reading it. Try reloading the page maybe?
Re: OxCaml - a set of extensions to the OCaml programming language.
#30Earlier quoted context omitted.
FWIW, the "Get OxCaml" page actually says that SIMD on ARM isn't supported yet. If it actually works it would be worth removing that from the known issues list https://oxcaml.org/get-oxcaml/
Indeed, it says that because we don't have a library of NEON intrinsics (like ocaml_simd_sse) yet, but the extension itself works.