@suhailshergill I'd have some time over the WE to put into the library - I've used eff a bit in scala, but I haven't fully understood the paper. Where should I start for some reasonable results in terms of contributions

Suhail Shergill

@suhailshergill

@reactormonk I'm currently on vacation with limited Internet connectivity. Unfortunately I won't be able to be of much help this weekend. Let me see what I've pushed in the repo

Suhail Shergill

@suhailshergill

@reactormonkhttps://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)

Suhail Shergill

@suhailshergill

Since the library doesn't have a very well fleshed out test suite I was interested in porting the cut example. But another possible contribution angle might be for you to flesh out the tests for Eff1 (and add new ones)

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

@power-fungus in extensible-effects it isn't one effect over another. the main difference is that Trace is for IO. it has a narrow purpose (to add "trace" commands in IO)

could this be done by generalizing Writer. probably, by combining it with Lift

power-fungus

@power-fungus

@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

@power-fungus

I see the narrow purpose of Trace, however, I think it is a bit too narrow for this library. If desired, I can try to design a logging-effect, which would cover the Trace, but also implements more general logging primitives.

Suhail Shergill

@suhailshergill

@power-fungus i like the idea of a "logging" or "debug" effect which extends Trace (it may do this via Writer or by other means)

power-fungus

@power-fungus

I would gladly tackle that with my friend @fendor. We would do this via some other logging algebra. If you have a resource describing a logging-algebra design you can let me know :)

Suhail Shergill

@suhailshergill

This message was deleted

@power-fungus there are a few practical options i'm aware of (with relatively simple algebras). these may give you some ideas: