Active maintenance?

[isovector]

Hi IxpertaSolutions -- this project seems to be inactive, but we’re using it to great success at Takt (takt.com). Would you like some help maintaining it, if not having us taking it over? We can throw some full-time resources at the task :)

[liskin]

Hi. You're right that we've been stalling lately, mostly because we worked on projects that didn't involve freer-effects or Haskell, and some guys were busy with vacations, exam periods, etc. Unfortunately I feel that our perfectionism isn't all that compatible with your fast-paced dynamic development workflow and I'm afraid we wouldn't be comfortable with you merging stuff that isn't up to our (arguably somewhat impractical) standards.

I'd appreciate if you could live with your internal fork for some time and I hope we'll think of a way to continue forward, either via us allocating more resources or admitting we can't keep up, or something else. (As far as I'm concerned, I'd be most happy if we agreed that our high standards are useful and desirable and we found a community member or two who would be interested in helping review stuff, but it is a very selfish wish. :-))

[liskin]

(Somewhat relatedly, @xkollar might be interested in http://takt.com/careers/haskell-engineer/ :-))

[schell]

@liskin I know you guys have told me before of your design/code standards, do you have a link to a write up? I can't find that discussion at the moment.

[lexi-lambda]

I realize this is a somewhat old thread, but I, too, am interested in what the current state of things is. The package fragmentation already seems sort of bad—there is both freer and freer-effects—and it would be really nice to have a single, actively maintained package. (I ask because I have some ideas I might turn into PRs, and it’d be good to know in advance if they’re not likely to ever get merged.)

[isovector]

@lexi-lambda We at Takt have made our own fork and can commit to maintaining it if there is community interest. It doesn't help the fragmentation problem, unfortunately, but it might be better than nothing. https://github.com/TaktInc/freer

[liskin]

@isovector You could have taken at least the good bits from our fork, if not everything... :-P

[liskin]

(But to answer the original question, I'll be leaving paid Haskell development in less than two months, so chances of our fork becoming more active are likely grim.)

[schell]

@liskin what are the most important bits that you could suggest we integrate?

[lexi-lambda]

The irony here is that, after I made the comment with a plea for less fragmentation, I promptly went off and forked this package and rewrote its interface extensively. This is really just an experiment, but so far it seems like it’s working alright for the things I’ve been playing with it for.

You can see the main API in Control.Monad.Freer in my fork. You can see it in action in the updated Console example. One of my main goals so far has been trying to make writing testable, effectful Haskell easier, especially to newer Haskellers. A couple of people looked at the type signature of handleRelay and seemed a little spooked.

So far, this simplified API seems somewhat promising (it’s missing some things, like stateful interpreters, but generally I haven’t found any effects we’ve used that need that but can’t just use State internally), but I would ideally like to avoid forking again and polluting the package ecosystem even more. I’m not sure if there’s a good way around doing so, though, since I’d like to expose a much simpler, smaller API (and adding a separate module like Control.Monad.Freer.Simple seems more confusing than helpful).

I’d be curious what your thoughts are on both my take on the API and the ecosystem fragmentation issue. I’m not completely sure that we’ll make the jump over to freer either way, but having a well-maintained package with an API I feel confident training new Haskellers in would go a long way towards making it more appealing.

[liskin]

@schell travis, changelog, runNatS, forever loop tests. Perhaps more. Frankly, I'm a bit surprised you started off freer instead of freer-effects which already had a lot of stuff merged and cleaned up. Is our coding style really that appalling?

[spacekitteh]

@lexi-lambda I really like that fork! You should submit a PR if you haven't already.

[lexi-lambda]

@spacekitteh My fork is not backwards-compatible because it removes exports from Control.Monad.Freer, so a PR with the changes as-is would probably be a bad idea. I could reintroduce the old interface and reorganize the exports, but I’m also not actively using this for anything, so my fork was mostly just an experiment.