I don't know OCaml so can't compare; vs Haskell the effects system is finer-grained and more "reflectable" / easier to reason about, while also letting you do more "impure" stuff more ergonomically.
Another aspect I'm excited about is their memory management system, which is basically "reference counting but good"; the combination of reference-counting with mostly-immutable stuff means that the programmer can write "pure" code that compiles to in-place operations, sometimes resulting in performance more like C than a typical ML-derivative.
Ah, I assumed you meant the built-in systems since in Haskell iirc there are a bunch of different libraries that all do effects in slightly different ways. I have vaguely looked at some of them but have also not really explored enough to know.
OCaml's effects system was much talked about but not yet released at the time I left Jane Street and largely stopped doing OCaml, so I don't know much about it except that it exists, and it looks superficially similar to the Koka examples I saw
I was about to say the same, inspired by your previous thread! I tried it out a tiny bit; it's neat but very much a research prototype (eg I couldn't even find sorting in the standard library)
Unlike languages such as Eff and Koka, effect handlers in OCaml do not provide effect safety; the compiler does not statically ensure that all the effects performed by the program are handled. If effects do not have a matching handler, then an Effect.Unhandled exception is raised at the point of the corresponding perform.
the delimited continuations in OCaml must be used linearly – every captured continuation must be resumed either with a continue or discontinue exactly once. Attempting to use a continuation more than once raises a Continuation_already_resumed exception.
It is left to the user to ensure that the captured continuations are resumed at least once. Not resuming continuations will leak the memory allocated for the fibers as well as any resources that the suspended computation may hold.
whereas I think Koka ensures things don't leak and also lets you resume multiple times, so you can do things like this: github.com/koka-lang/koka/blob…
Ben Millwood
in reply to Ben Weinstein-Raun • •Ben Weinstein-Raun
in reply to Ben Millwood • •I don't know OCaml so can't compare; vs Haskell the effects system is finer-grained and more "reflectable" / easier to reason about, while also letting you do more "impure" stuff more ergonomically.
Another aspect I'm excited about is their memory management system, which is basically "reference counting but good"; the combination of reference-counting with mostly-immutable stuff means that the programmer can write "pure" code that compiles to in-place operations, sometimes resulting in performance more like C than a typical ML-derivative.
Ben Millwood
in reply to Ben Weinstein-Raun • •to be clear when I say Haskell effects I mean something like hackage.haskell.org/package/fu… rather than just the IO monad by itself
the memory management thing does sound interesting, though personally I don't write anything perf-sensitive enough to care :P
Ben Weinstein-Raun
in reply to Ben Millwood • •Ben Millwood
in reply to Ben Weinstein-Raun • •OCaml's effects system was much talked about but not yet released at the time I left Jane Street and largely stopped doing OCaml, so I don't know much about it except that it exists, and it looks superficially similar to the Koka examples I saw
read more: ocaml.org/manual/5.2/effects.h…
like this
Daniel Ziegler and Ben Weinstein-Raun like this.
Daniel Ziegler
in reply to Ben Weinstein-Raun • •Ben Weinstein-Raun likes this.
Daniel Ziegler
in reply to Ben Weinstein-Raun • •One downside of OCaml's implementation:
Ben Millwood likes this.
Ben Millwood
in reply to Daniel Ziegler • •Daniel Ziegler
in reply to Ben Weinstein-Raun • •The other downside:
whereas I think Koka ensures things don't leak and also lets you resume multiple times, so you can do things like this: github.com/koka-lang/koka/blob…
like this
Ben Weinstein-Raun and Ben Millwood like this.
Daniel Ziegler
in reply to Ben Weinstein-Raun • •Apparently I was wrong about the standard library not having a sort function - it's just undocumented AFAICT! github.com/TimWhiting/advent-2…
Oh, I see, it's in the community std library: github.com/koka-community/std/…
advent-2024/day1.kk at main · TimWhiting/advent-2024
GitHubBen Weinstein-Raun likes this.