Retrofitting Effect Handlers onto OCaml · HackerPapers discussions

Retrofitting Effect Handlers onto OCaml — mentioned by grumpyprole

Thu, 30 Mar 2023 06:23:15 GMT

> Do you have any good resources on OCaml5 effect handlers I can follow? I encourage you to have a look at the published paper, it's an easy read and covers the motivation and examples: https://arxiv.org/abs/2104.00250 Here's an excellent talk that walks through modifying a non-trivial code base for concurrency using effect handlers: https://youtu.be/k3oQwpyXmpo > It does feel to me like error's and async's both should remain orthogonal They aren't completely orthogonal though, as both are effects. Haskell and Rust model both with Monads. OCaml 5 can model both with effect handlers. It is…

Paper and discussion history. A mention is not an endorsement.

Retrofitting Effect Handlers onto OCaml — mentioned by sadiq

Fri, 16 Dec 2022 22:37:28 GMT

We certainly hope so. You may find Thomas Leonard's talk from last year's workshop interesting: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5... The paper we wrote on retrofitting effect handlers: https://arxiv.org/abs/2104.00250 also has some http benchmarks

Paper and discussion history. A mention is not an endorsement.

Retrofitting Effect Handlers onto OCaml — mentioned by wahern

Thu, 30 Jun 2022 07:23:09 GMT

Non-contiguous stacks are typically just linked-lists of call frames, or groups or call frames. One of the examples that used to be regularly trotted out comp.lang.c 15+ years ago was an IBM mainframe environments, where stacks were linked lists but still managed by hardware. Off the top of my head, current examples of non-contiguous stacks on more familiar system with supporting code compiled directly to machine code (i.e. not language interpreters and VMs, where this is actually very common), include 1) gccgo, which compiles Go code to use split stacks. 2) gcc with -fsplit-stacks, which…

Paper and discussion history. A mention is not an endorsement.

Retrofitting Effect Handlers onto OCaml — HN submission

Tue, 10 May 2022 12:41:54 GMT

Retrofitting Effect Handlers onto OCaml

1 point; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Retrofitting Effect Handlers onto OCaml — mentioned by sadiq

Mon, 10 Jan 2022 16:06:27 GMT

It involved a fair amount of research and there were many technical challenges. Maintaining backwards compatibility in terms of language features and single-threaded performance puts constraints around what you can implement. Also from my personal experience, debugging segfaults in parallel programs that could be caused by GC bugs is a painstaking process. We've written a couple of papers detailing the internals and the trade-offs involved: https://arxiv.org/abs/2004.11663 (for parallelism) and https://arxiv.org/abs/2104.00250 (for effects) Added to that is the complexity of tracking a moving…

Paper and discussion history. A mention is not an endorsement.

Retrofitting Effect Handlers onto OCaml — HN submission

Wed, 08 Dec 2021 07:18:37 GMT

Retrofitting Effect Handlers onto OCaml

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Retrofitting Effect Handlers onto OCaml — mentioned by kcsrk

Fri, 14 May 2021 03:53:20 GMT

Abandoned is perhaps too strong a term :-). Effect handlers in the language are supported by fibers, lightweight stacklets managed by the runtime. The details of the implementation can be found in the upcoming research paper in PLDI'21 conference [1]. The effect handlers in Multicore OCaml today do not provide effect safety. Programs are not statically guaranteed to handle all the effects they may perform. This is only as bad as exceptions in OCaml and every other mainstream language with exceptions. We are working on developing an effect system, which will ensure effect safety i.e, the…

Paper and discussion history. A mention is not an endorsement.

Retrofitting Effect Handlers onto OCaml — mentioned by sadiq

Thu, 13 May 2021 14:50:40 GMT

Good questions! 1) As I mentioned in https://news.ycombinator.com/item?id=27142502 there is support for parallelism and concurrency. Giving an example of where these might be useful in a webservice. The addition of shared-memory parallelism is beneficial where you might have a great deal of shared state that needs to be used to service requests. An in-memory cache is a good example - with a processed-based approach managing read/writes and avoiding significant overhead from marshalling the data is difficult. Concurrency via effects at a minimum can make writing network-based services much…

Paper and discussion history. A mention is not an endorsement.

Retrofitting Effect Handlers onto OCaml — mentioned by sadiq

Thu, 13 May 2021 14:33:00 GMT

Not dumb questions at all. Multicore adds parallelism via Domains (which are essentially heavyweight threads) and concurrency via Effects and fibers. There's a multicore GC that supports both of those. We plan to upstream things in two parts. First domains-only parallelism and then effects as a follow-up. When the latter lands users will be able to define their own effects and handlers, yes. Performance is pretty good, you can see our PLDI2021 paper for a proper performance evaluation and loads more details: https://arxiv.org/abs/2104.00250

Paper and discussion history. A mention is not an endorsement.