Is it possible to write a handler for a built-in effect like Console?

[osa1]

As the title says, I'm wondering if I can write a handler for the effect types defined in the library, like Console: https://hackage.haskell.org/package/effectful-2.4.0.0/docs/Effectful-Console-ByteString.html.

Looking at the source code, this effect does not seem to have any constructors: https://hackage.haskell.org/package/effectful-2.4.0.0/docs/src/Effectful.Console.Effect.html#Console

And the operations of this effect seem to be directly calling the IO functions: https://hackage.haskell.org/package/effectful-2.4.0.0/docs/src/Effectful.Console.ByteString.html#getLine

So I think the answer is no?

If I get this right, then how do I handle effects of e.g. a library code that I don't have control over that uses one of these built-in effects like Console and Error?

Thanks.

[ocharles]

This effect is defined as a statically dispatched effect which means it only has a single interpretation. So there is no way to redefine Console.

[osa1]

But isn't the point of an effect library to give control to the caller over how the effects are performed, and where? It's a bit strange that there are effects that you cannot handle.

Anyway, thanks.

[ocharles]

I think it's up for debate exactly what should be static and what should be dynamic. I admit I'm not entirely sold on the whole static thing. I know you get a minor performance gain but it comes at quite a cost - exactly this problem! It's very hard to work out if in the future someone will want to reinterpret your effect

[arybczak]

Effects in the effectful package are all statically dispatched mostly because the goal of the first iteration was to take some stuff from base and unliftio and divide it into effects so that you can say "this function only has access to the file system and spawns processes" as opposed to "this function does arbitrary IO". This is what static dispatch is good for mostly. Also, sometimes ensuring that the interpretation can't change at runtime is a perk in itself (like when you want to require thread local State, because the implementation for some reason wouldn't make sense with the shared State).

It also wasn't clear to me whether there exist other relevant interpretations of these effects.

The good news is that statically dispatched effects are API wise forward compatible with being made dynamic, so there's nothing in principle preventing us from making them dynamic (or providing a dynamic variant) when it turns out alternative interpretations make sense.

Would you mind expanding what it is exactly you planned to do that the current design prevents?

[osa1]

Would you mind expanding what it is exactly you planned to do that the current design prevents?

I don't use Haskell for anything serious these days, so this is not really a blocker for me.

I'm exploring effect systems and experimenting with some ideas, and not being able to handle effects goes against my definition of effect systems, which is all about giving the user control over (1) how effects are performed (with handlers) and (2) where (with tracking them in the types).

Of course, no one has to agree with my definition on what an effect system should do. You can certainly do just (2), as is the case with the static effects of this library.

More concretely, I wanted to experiment with testing concurrent code, similar to dejafu, but I also wanted the code to do IO, as that is what most real-world code would do. dejafu works with concurrency monads, which don't do file IO, printing etc., so I can't use just that.

effectful seemed like a better library in terms of ergonomics (types, type errors, how you write handlers) and completeness (has effects for concurrency, file IO, printing, ...), but none of them can be handled. So I cannot test my effectful code in a way I can test my concurrency code (with dejafu).

[arybczak]

So I cannot test my effectful code in a way I can test my concurrency code (with dejafu).

You can, just define your own effect that includes parts of the API from these effects you want and provide two handlers.

Defining new effects with effectful is easy 🙂

[osa1]

Haskell's concurrency API (also including the async package) is not small, and I wouldn't be able to use someone else's code (e.g. a library) that use the effectul's built-in concurrency effect with my code. So I don't think that's a viable solution.

[arybczak]

Fair point.

If someone demonstrates that a dynamic Concurrent effect makes sense (e.g. that it's possible to write something like io-sim with effectful), it would make sense to make it dynamic

Concurrent in particular is static because of the assumption that there is no alternative implementation that makes sense.

[osa1]

If someone demonstrates that a dynamic Concurrent effect makes sense (e.g. that it's possible to write something like io-sim with effectful), it would make sense to make it dynamic

Concurrent in particular is static because of the assumption that there is no alternative implementation that makes sense.

Isn't dejafu-style testing useful? I've never used it myself, as mentioned, I wanted to try it but it didn't have everything I needed (file IO). Maybe it's not as useful as I think?