or close enough
Eff (State Int : Reader Int : []) () ;)
are type-level Sets possible?
or is it feasible that someone would want multiple
State Int per effect stack?
it's part of ghc's support for datakind promotion https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/promotion.html not sure if it's an error or warning when it is omitted
it = quote
an implementation of type-level set https://hackage.haskell.org/package/type-level-sets
I would if that would be useful for EE
i've been aware of it, but didn't want to take the plunge into type-level quicksort just yet https://github.com/dorchard/type-level-sets/blob/3941dae6a26705a45faa064aab296417f7bfa621/src/Data/Type/Set.hs#L156
that's hilarious
such kind of type "towers" (value -> type -> kind -> ...) leads to another notion of polymorphism. it would be great to be able to write a generic quicksort algorithm which is applied at the various levels. i.e. universe polymorphism http://adam.chlipala.net/cpdt/html/Universes.html and https://coq.inria.fr/refman/Reference-Manual032.html
@reactormonk https://github.com/suhailshergill/extensible-effects is the personal branch where I've been parking the changes (to address issue suhailshergill/extensible-effects#56 ) it's mostly done. The one last piece of code (it's an example) left to port is the cut example (around line 1016 in https://github.com/suhailshergill/extensible-effects/blob/sss/freer/src/Control/Eff1.hs ). The commented portion below (right at the end, is from the older design of eff. As you can see in the code I started the process to port it but didn't get very far. If you have time to donate it would help to see what that example would port like (and if you do that you would probably have a deep understanding of both eff and non-determinism)
If you want an easier challenge, starting to replace all the Eff examples and tests with the Eff1 ones would help (and refactoring appropriately). Currently all the new stuff should be in Eff1 (and possibly other files with the 1 suffix) and the commented out code examples from Oleg as tests in the test suite (alongside older Eff tests). The sanest order would be to align and mirror the tests and code for Eff with Eff1 and then remove the older ones (piecewise or monolithically)
I will be afk for the rest of Friday and all Saturday (flying back in on Saturday eve). Depending on how I recover from the jetlag I might be able to form some semi-coherent thoughts sometime Sunday (but don't hold your breath)
Hopefully the above gives you a place to start and independently tinker
what makes it special over
Writer?
relates to #106
could this be done by generalizing
Writer. probably, by combining it with Lift
@suhailshergill Technically, you would be right that the effects are independent from each other. However, a library should be coherent in its intent and lead the programmer using the library to good designs by exposing some functions and not implementing others. I think that having the trace effect with no statement of when it should and when it should not be used leads to confusion for new users.
See my commit power-fungus/extensible-effects@c4131e7 for a re-implementation of
runTrace using Writer
@power-fungus there are a few practical options i'm aware of (with relatively simple algebras). these may give you some ideas:
@suhailshergill I implemented a new effect almost identical to the Exception one except that it is called Success. It is inspired by http://hackage.haskell.org/package/errors-2.2.5/docs/Data-EitherR.html.