
Adding an Effect System to OCaml [video] - tosh
https://www.janestreet.com/tech-talks/effective-programming/
======
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](https://github.com/ocamllabs/multicore-opam)

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

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

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

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

~~~
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](https://nim-lang.org/docs/manual.html#effect-system)

~~~
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...](https://koka-lang.github.io/koka/doc/kokaspec.html#sec-a-primer-on-effect-handlers)

* 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](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.

