Comments (18)
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 ?
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.
Related Issues (20)
- Spurious ci-test-error with trace HOT 7
- RFC: Version semantics HOT 2
- Decide on: support GHC 8.0 vs use pattern synonyms in implementations HOT 7
- Undeclared `TypeApplications` extension HOT 1
- call for maintainer HOT 15
- RFC: Handle class HOT 8
- Chain multiple 'runError' calls into a single one.
- `SetMember Lift (Lift IO) r` doesn't seem to be sufficient to line up the function context for lift. HOT 4
- Build failure with GHC 8
- MonadError, MonadThrow, MonadCatch, MonadMask instances for module Exception HOT 8
- Alternative and MonadPlus instances in the module Choose HOT 2
- enable Alternative and MonadPlus instances for Choose in ghc-7.8 HOT 1
- Remove usage of deprecated OverlappingInstances HOT 4
- MonadBase and MonadBaseControl instances HOT 12
- Add explicit implementation for `*>` to be compatible with new `forever` HOT 2
- -Werror HOT 2
- Argument ordering of run* functions HOT 7
- adapt build and CI steps to use stack HOT 1
- improve performance for single-effect uses HOT 4
- Documentation: Detailed Introduction to all Effects HOT 16
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from extensible-effects.