Live data from Hacker News

OxCaml - a set of extensions to the OCaml programming language.

oxcaml.org

21–30 of 128 posts

Re: OxCaml - a set of extensions to the OCaml programming language.

#21
post #9

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…

they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around. a lot of times with tuple return types you're left wondering what that random `usize` is supposed to represent, so having names for it would be very convenient. i don't see why, under the hood, it couldn't just be implemented the exact same way as current tuple return types

Re: OxCaml - a set of extensions to the OCaml programming language.

#22

The 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...

Yeah, pretty excited about this one even though it seems minor. A paper and talk by the author of this particular feature from ML2024, too:

- 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.

#23

I 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)

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.

#24
post #20

Earlier 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.

> > 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.

#25
post #7

The 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…

GC compactions were indeed a problem for a number of systems. The trading systems in general had a policy of not allocating after startup. JS has a library, called "Zero" that provides a host of non-allocating ways of doing things.

Re: OxCaml - a set of extensions to the OCaml programming language.

#26
post #23

Earlier 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/

Indeed, it says that because we don't have a library of NEON intrinsics (like ocaml_simd_sse) yet, but the extension itself works.

Re: OxCaml - a set of extensions to the OCaml programming language.

#27

I 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)

Cool to hear there aren't any technical blockers to add Windows support! You just convinced me into giving OxCaml a try for a hobby project. 128-bit SSE is likely to be enough for my use case and target specs.

Re: OxCaml - a set of extensions to the OCaml programming language.

#28
post #7

The 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.

[deleted]

Re: OxCaml - a set of extensions to the OCaml programming language.

#29
post #20

Earlier 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?

Your comment remains completely stupid regardless of how much of it is in the quote. OxCaml's goal is to be upstreamed. "I don't see the point in this unless people have programs using OCaml" and it's like, yeah, that's the point of adding features to a computer program. Any computer program. Because people already use the computer program and it will be useful to them.

Re: OxCaml - a set of extensions to the OCaml programming language.

#30
post #23

Earlier 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.

Ah, that clears it up a bit. Thanks! Looking forward to all of this. (For the interested readers, here's the SSE library: https://github.com/janestreet/ocaml_simd/tree/with-extension...)
Post reply on HN