Incorporate updates from recent paper (i.e. use alternate definition of Free w/o Functor constraint) about extensible-effects HOT 18 CLOSED

a teaser of what Reader effect will look like in the new version: https://github.com/suhailshergill/extensible-effects/blob/sss/freer/src/Control/Eff/Reader/Strict1.hs note the lack of Typeable constraint :)

from extensible-effects.

Clever.

Lazy state and lazy writer compose, no?

Is there an option for how to make such an explicit Delay/demand based computation model more composable when all of the effect types are demand-drivable?

from extensible-effects.

Is there any eta on this ?

Having a fast extensible-effects equivalent to transformers or mtl with proper community advertising could really start the adoption.

from extensible-effects.

I'm aiming for end November, but if you'd like to contribute a patch in the
meanwhile I'll be happy to review.
Retaining the new version of open union (which has order n performance
operations) alongside the old is proving to be tricky however, and that's
where most of the complexity is. Are you running into scenarios at present
where the current implementation isn't satisfactory?

On Wed, Nov 18, 2015, 03:33 Rémi Vion [email protected] wrote:

is there any eta on this ?
Having a fast extensible-effects equivalent to transformers or mtl with
proper community advertising could really start the adoption.

—
Reply to this email directly or view it on GitHub
#56 (comment)
.

from extensible-effects.

@ekmett missed your comment on this previously, my bad. i don't often find myself relying on (or rather i try not to rely on) such delay/demand based computation model, so unfortunately i am out of my depth here. that being said, could you qualify/paint a picture of what you were thinking of/had in mind. i don't believe i fully grasp the scenario you're thinking of.

from extensible-effects.

Is the freer package superseding the extensible-effects package ?

• "freer" source on gitlab
• "freer" on hackage
• "freer" changelog on hackage

from extensible-effects.

I think it depends on what you need. Freer currently is the package which
has the improvements from the "freer" paper. My goal with
extensible-effects is to continue to support some of the alternate designs
outlined in the previous papers as well but haven't had enough time to
devote to it due to personal reasons. If you want something which
incorporates the newer ideas and works today, it seems like freer fits the
bill.

On Mon, Jan 4, 2016, 18:59 Rémi Vion [email protected] wrote:

Is the freer package superseding the extensible-effects package ?

• "freer" source on gitlab https://gitlab.com/cpp.cabrera/freer
• "freer" on hackage http://hackage.haskell.org/package/freer
• "freer" changelog on hackage
  http://hackage.haskell.org/package/freer/changelog

—
Reply to this email directly or view it on GitHub
#56 (comment)
.

from extensible-effects.

thanks for your quick response :)

from extensible-effects.

np :)
ooc, could you elaborate on the capacity to which you're using the ideas of
extensible effects/freer? is it for personal projects? is it from the
perspective of a library user, or more from the perspective of a library
author yourself?

On Tue, Jan 5, 2016 at 4:40 AM, Rémi Vion [email protected] wrote:

thanks for your quick response :)

—
Reply to this email directly or view it on GitHub
#56 (comment)
.

Suhail

from extensible-effects.

@suhailshergill I'm interested in extensible effects both as a library user and library author, and both for personal and professional projects.

I like the idea of extensible effects because for the simplicity of the concept, the sharability of code blocs, testing facility, the possible variety of interpreters for a same effects, etc. Nothing really new here. The raise of extensible effects in idris, purescript, and the the various recent Oleg articles and papers pretty much convinced me to give it an other try. Also, I feel a bit sad to start building libraries on transformers knowing that I'll probably never be able to easilly reuse them.

Speed is not really critical for me, but I'd like to use the new freer approch because:

• I want to see how bad look type errors with the new freer implementation, so I know how newcomer-friendly it is (this is one of the main reason for me to try the new freer approach)
• I hope that some of inference problems I had when playing with extensible-effects will be solved with the new closed type families implementation of data types à la carte
• I'm happy to think I'm not relying on Typeable and overlapping instances
• I'm don't know if I'll really need lazy effects, but I'm hapy to know I'll be able to if I need to.

Also, I'm not really concerned about the interpreters not obeying the monad laws. I think the error surface remains small, and that "cheating" may be fine in some cases.

I know that things will keep moving, maybe open unions will change to use future overloaded labels or row types, etc. but anyway, I don't want to wait for perfection forever, it may never come :)

from extensible-effects.

The example given doesn't seem to demonstrate any composability. That is, you explicitly choose the effect stack to just be state. Is it possible to extend this approach to any arbitrary stack of effects?

from extensible-effects.

@ocharles i believe it's possible to have consistent composable semantics between say lazy writer and state (though the above example doesn't demonstrate it). it's not clear to me what the semantics you'd want to ascribe to compositions where not everything is demand driven.
could you illustrate with an example what you're attempting to accomplish?

from extensible-effects.

I'm afraid I have no example, I'm not trying to do anything (I don't use extensible-effects) - I'm just interested in this area.

from extensible-effects.

@ocharles understood. in that case the excerpt below (from my discussion with oleg) following up from edward's motivating example might be of interest to you:

-- The example only makes sense with the *closed*, non-extensible set of effects. Indeed,
-- let us first remove the given signature of foo to make it somewhat
-- open (although not quite: the signature of modify makes StateT to be
-- the topmost, outer effect -- which is the limitation: I can't put more
-- effects on the top of State, only below. This is not the drawback of
-- transformers per se, only of the particular transformers library)

foo = do
  foo
  modify (1:)

arg:: [Integer]
arg = [1, 2, 3]

bar:: ((), [Integer])
bar = runState foo arg

baz:: ()
baz = fst bar
-- returns ()

qu:: [Integer]
qu = take 3 $ snd bar
-- returns [1, 1, 1]

-- Now, I add another effect, using the same foo, to test
-- extensibility. Although foo does not use the Error itself, foo can be
-- combined in the whole program with another function that does use
-- Error:

bar1 :: Either String ((), [Integer])
bar1 = runIdentity $ runErrorT $ runStateT foo arg

qu1:: [Integer]
qu1 = take 3 $ snd (either (error "error") id $ bar1)
-- diverges


-- And now qu1 diverges. This shows that the given example is irrelevant
-- for the discussion of extensible effects and modular effect libraries
-- as it is unmodular and uncomposable. It also illustrates how fragile
-- the lazy tricks are: as much as looking at the program the wrong way
-- may send it in the infinite loop.

from extensible-effects.

Very interesting, thank you!

from extensible-effects.

an update for those subscribed to this issue.
i've been able to port most of the effects (including coroutines) to the new implementation of Eff1. in addition, i have also settled on an open-union implementation which works across ghc compiler versions (the implementation internally uses unsafeCoerce and so i will need to add some tests for it). this is all very good news, because those were two of the biggest hurdles in incorporating ideas from the freer paper.

so, while there's still work left to do the rest should be much more straightforward. i'm looking forward to being able to make a release soon :)

from extensible-effects.

Yeah! :-) I am currently using the freer package for my work and I like it. Looking forward to replacing it with extensible-effects!

from extensible-effects.

I use extensible-effects in many of my projects and am always looking forward to improvements.

from extensible-effects.