I'm in favor of keeping just EnvIO and make the ot...

# arrow

[pakoito]

I'm in favor of keeping just EnvIO and make the other two an alias using Nothing for the fields they don't use.

[raulraja]

The issue is that for what we've found so far some optimizations can't be applied to EnvIO directly

[raulraja]

@simon.vergauwen

[simon.vergauwen]

While I think typealias IO<A> = EnvIO<Nothing, Nothing, A> is very elegant but I do share @raulraja his concern about the optimisations.

[simon.vergauwen]

I am not sure how much of a maintenance headache having 3 effect types will result in nor how much of a difference it’ll be.

[raulraja]

If we want performance so far we found different data types is faster because we can apply individual optimizations as to how effects are processed and programs are composed with flatmap

[pakoito]

The issue is that for what we've found so far some optimizations can't be applied to EnvIO directly

such as?

[raulraja]

We are using now mutation in the ADTs to avoid allocations if we find a consecutive node

[raulraja]

In EnvIO all values are functions

[raulraja]

And we can't optimize pure, map, flatmap etc as directly over io

[raulraja]

Because there is always the additional allocations

[simon.vergauwen]

EnvIO is (R) -> IO<E, A> right?

[raulraja]

yes

[raulraja]

but with special combinators to inject the effect of that shape

[raulraja]

effect can take one of those and bind to A