Ollie Charles

I'm going to need this for paid work in the next few days, so anyone willing to provide pointers I'm certainly interested in helping implement stuff.

I feel like I have something that's working nicely now, you can compare the work I've done so far in https://github.com/ocharles/digestive-functors/compare/input-list. The remaining outstanding work is: - `digestive-functors-snap` won't work...

Oh, I'd also like to know if the Heist/Happstack stuff needs to be done before we can release this. Neither of those are libraries I have really ever used, so...

- The only way for `digestive-functors` to deal with it is to pass the entire list of possible values over in the `Env` and have `digestive-functors` mangle it apart. If...

It's a tricky one! On the one hand, I don't like having an error at all because it feels like it should be valid to construct that form (in fact,...

If you only need `extend` you could also ask that to be passed in as a parameter. Not sure if that permits other "interesting" `extend`s

Well, I suggest it more from wondering if as you only want `Extend` you really do just want to supply that function. Plus, maybe it means something interesting (like `traverse`...

I think Eq1 and friends just have the advantage of requiring less type extensions. On Thu, 9 Mar 2017, 2:51 pm michaelt, wrote: > Oh that's true. I was thinking...

I can't say I'm particularly in support of this. Seems like clever for clever's sake. If it could at least be verified with a benchmark, I'd be more inclined.

The `pipes-safe` approach to lifting `mask` seems to work: ```haskell data Restore m = Unmasked | Masked (forall x . m x -> m x) liftMask :: forall m f...