HN Theater @HNTheaterMonth

Upcoming OCaml multicore won't expose effects at all. I believe the intention is to finish work on typed effects[1] and only then add it to the language.

[1]: https://www.janestreet.com/tech-talks/effective-programming/

⬐ pdimitar

They have an effects branch but admitted it won't be ready in time for OCaml 5.0 (supposedly arriving around end of 2021 / early 2022) so they have a separate compiler variant with it where the progress can be tracked.

Last I read, they really want to nail down the entire multi-threaded environment to the last detail first (which mostly means make sure no parallel bugs are introduced + single-threaded code won't become slower; both pretty huge goals).

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 compiler ensures that all the effects performed are caught. You also get a nice inferred type that says what effects a particular function may perform; if it performs none, then it is a pure function! This implementation would still use the current fiber support in the runtime. Leo White, one of the developers of Multicore OCaml had given a talk on this new effect system a few years ago [2]. That's the best place today to learn about the new effect handlers.

The plan is to first add the fiber runtime support to OCaml without the syntax extensions for effect handlers, and then introduce syntax along with the effect system.

[1] https://arxiv.org/abs/2104.00250

[2] https://www.janestreet.com/tech-talks/effective-programming/

Ocaml (almost ?) has it. https://www.janestreet.com/tech-talks/effective-programming/

Pure functional languages such as Haskell have some facilities to do things that are not 100% pure, such as I/O. Similarly, OCaml has effects, but functional programmers minimize their use of such impure facilities.

Effects in OCaml are impure: "However, the effect system also allows for tracking side-effects more generally. It distinguishes impure functions, which perform side-effects, from pure functions, which do not." See: https://www.janestreet.com/tech-talks/effective-programming/

In Haskell impure functions are fenced off from pure functions. So for example, pure functions are not allowed to call impure ones.

If nearly all of the functions in your app are impure (and use React hooks) then you are definitely not doing functional programming.

⬐ galaxyLogic

> In Haskell impure functions are fenced off from pure functions

That's a great way of explaining it. But at the same time how can we say that Haskell is a "pure functional language" when Haskell programs consist of both pure and impure functions?

Yes they are separated which in other words means you do have both of them. Is that really "pure" then? Or is that more like 'as pure as possible"?

⬐ mejutoco

According to this definition a pure programming language could not have any side effect (Not very useful). Maybe as pure as possible is the only interpretation that makes sense, then.

⬐ whimsicalism

Agreed - I do not think purity should be core to the definition of what a functional language is.

⬐ flowerlad

Pure functions (with no side effects or state mutation) is pretty core to functional programming.

⬐ whimsicalism

https://en.wikipedia.org/wiki/Functional_programming

> Functional programming is sometimes treated as synonymous with purely functional programming, a subset of functional programming which treats all functions as deterministic mathematical functions, or pure functions. When a pure function is called with some given arguments, it will always return the same result, and cannot be affected by any mutable state or other side effects.

It is a closely associated idea, but it is not necessarily "core" to what FP is.

⬐ whimsicalism

> Effects in OCaml are impure:

I didn't think that OCaml had a way of distinguishing functions with side effects... the link you sent seems to describe a prospective extension/system, not a built-in of the language.

⬐ ernst_klim

> prospective extension/system, not a built-in of the language

Yes, that would be merged into the language as typed algebraic effects branch.

Please see [1]. Around 28:45 the talk moves to effect types. At around 29:25 the proposed mechanism (with throw) is literally described as "checked exceptions".

AFAIK, this is all part of the roadmap.

[1] https://www.janestreet.com/tech-talks/effective-programming/

⬐ rixed

Yes thank you, exactly what I was looking for.

⬐ cultus

I'm glad to see effect systems getting so much attention lately. I think they are a far better alternative to monads (and monad transformers) in terms of cognitive load. They commute, for example.

⬐ Kutta

You mean algebraic effects? Monad transformers are an effect system as well.

⬐ elcritch

Can you give an example/link of how they commute?

⬐ cultus

Eff is a language based on algebraic effects. They show some good examples. It's pretty cool.

https://www.eff-lang.org/

⬐ dwohnitmok

Apart from the sibling conmment pointing out that effect monads are one type of effect system, almost all effect systems I know of (algebraic effects included) have a monadic interface. The only one I can think of that doesn't is the family of uniqueness/linear/affine types (to the extent that those model certain kinds of effects).

Maybe you were mainly just thinking of monad transformers or combining discrete monads?

⬐ jkachmar

Definitely not as popular, but Arrow-ized effect systems are an interesting area that I've seen people exploring more lately.

Jake Keuhlen spoke about it at LambdaConf this year [0] [1], and John De Goes spoke a bit on the notion of Arrow-ized IO in the `zio` library for Scala that offers an alternative interface for `IO` effects [2].

Will Fancher has also written a bit on the concept of "Free Arrows", but it's a much deeper dive (IMO) than the previous resources [3].

[0] Keuhlen's Repo: https://github.com/jkeuhlen/talks/tree/master/extensibly-fre...

[1] Keulen's Slides: https://github.com/jkeuhlen/talks/blob/master/Extensibly%20F...

[2] https://github.com/scalaz/scalaz-zio/blob/master/core/shared...

[3] https://elvishjerricco.github.io/2017/03/10/profunctors-arro...

⬐ None

None

⬐ dan-robertson

I don’t understand what you mean by “monadic interface.” Could you elaborate on that please?

⬐ dwohnitmok

I just meant that you usually still end up using the equivalent of bind to compose things and pure to lift non-effectful code. I was thinking mainly of the free and freer monad here, but I think it applies generally.

⬐ cultus

I should have indeed said algebraic effects instead of effects system.

Algebraic effects are a restriction on monads, but a restriction that still allows for the vast majority of use cases. In return, you get composability and a clear separation of effectful operations and effect handling.

The default of using monads for everything produces too much cognitive complexity for little benefit.

⬐ dwohnitmok

Hmm... What do you mean by a restriction on monads? Algebraic effects basically mean that you live in a single monad that can be either widened or narrowed via new effects or new handlers respectively.

I'm also not sure what you mean by "using monads for everything." Monads are basically just flatten and map. It sounds kind of like "you're using map for everything" to which the answer seems something along the lines of, well in a lot of places where you use map, if you didn't use map, you'd probably just reinvent it.

⬐ dan-robertson

Algebraic effects (at least in multi core ocaml) are a restriction on monads because the function passed to bind in a monad may be run multiple times whereas the equivalent continuation after some effect may only be run once. Therefore one cannot use algebraic effects to eg do the equivalent of what the list monad does.

⬐ dwohnitmok

Hmm... Maybe I need to look at multi-core OCaml more closely, but I don't think it's true in general of algebraic effects (or at least its freer monad variants), as in I'm pretty sure I can emulate a list using them. In particular I'm pretty sure I can do that with `Cont` alone.

⬐ fmap

You're right, the linearity restriction on the handler continuation is a peculiarity of multi-core OCaml and really more of an implementation detail.

However, it is also true that you cannot encode, e.g., the continuation monad using (typed) algebraic effects. The precise relationship isn't that simple, but this paper:

  https://arxiv.org/abs/1610.09161

analyzes a particular setting in detail.

⬐ cultus

>Algebraic effects basically mean that you live in a single monad that can be either widened or narrowed via new effects or new handlers respectively.

Yep, it is a restriction as I said. Algebraic effects basically live inside the free monad, so that's what I meant by that.

This restriction, versus using separate Writer, IO, etc, monads, is far more easy to reason about. Types in Haskell become insane with monad transformers. It produces code that is difficult to understand and reuse.

edit: Algebraic effects can also be derived from delimited continuations.

⬐ dwohnitmok

Maybe I'm just getting hung up on the word restriction. In particular is there any monad that cannot be expressed as a pair of algebraic effects and handlers? I think the answer is no (potentially barring especially magical monads such as IO in its full generality), but I'm not sure.

Totally agree about the brittle and type-soup nature of transformer-heavy code.

⬐ dom96

For those interested in effect systems, here is a description of the effect system in Nim: https://nim-lang.org/docs/manual.html#effect-system

⬐ dwohnitmok

Ooo... Interesting! Are these significantly different from Java's checked exceptions (the reader and writer ones look interesting, but unfortunately are not yet implemented)?

⬐ yawaramin

I'm very interested in Nim's effect system. I have a few questions about it:

* Does it have a way to define effect handlers in a decoupled way from the effects? I'm looking for something like this: https://koka-lang.github.io/koka/doc/kokaspec.html#sec-a-pri...

* Are all standard library procs marked with all their actual effects?

* How complete is compile-time effect tracking right now? For example, the following doesn't raise a compile error:

    proc testEffects() {.tags: [].} = "hi".echo
    testEffects()

* Is there a 'strict effect' mode, that would implicitly add `{.tags: [].}` to all proc types without an explicit tags pragma? That would make effect tracking more, well, effective.

⬐ mc10

Here are some recent (June 2018) slides about multicore OCaml that provide some extra information about effect handlers: http://kcsrk.info/slides/mcocaml_gallium.pdf

⬐ calebh

I'm excited to see that effect handlers are gaining popularity. I read the original papers that introduced them, and I think that they have a lot of potential.

⬐ shitjanestre

Who gives a shit what janestreet does with ocaml . Come on guys , it this is getting old.

⬐ anuragsoni

If someone wants to try running `ocaml-multicore` there is an opam repository available [1].

I am currently doing the exercises from the "ocaml-effects-tutorial"[2]. This is the first introduction i've had to algebraic affects and the exercises are a fun way to play around with some code as I try to improve my understanding of how one might use the effect system.

[1] https://github.com/ocamllabs/multicore-opam

[2] https://github.com/ocamllabs/ocaml-effects-tutorial

The author of the talk here. I am excited about the Multicore OCaml upstreaming plan.

We're going to phase it into 3 distinct phases. First, we will upstream the multicore runtime so that it co-exists with the current runtime as a non-default option. This will give a chance to test and tune the new GC in the wild. Once we are happy with it, it will be made the default.

The second PR would be support for fibers -- linear delimited continuations without the syntax extensions (exposed as primitives in the Obj module). This will help us test the runtime support for fibers and prototype programs.

The last PR would be effect handlers with an effect system. Any unhandled user-defined effects would be caught statically by the type system. The effect system is particularly useful not just for writing correct programs, but to target JavaScript using the js_of_ocaml compiler where we can selectively CPS translate the effectful bits à la Koka. As a result, we will retain the performance of direct-style code and pay extra cost only for the code that uses effect handlers. In the future, we will extend it to track built-in OCaml effects such as IO and mutable refs. At that point, we can statically distinguish pure (as Haskell defines it) functions from impure ones without having to use Monad transformers for the code that mixes multiple effects. I'd recommend Leo White's talk [0] on effect handlers for a preview of how this system would look like.

[0] https://www.janestreet.com/tech-talks/effective-programming/