Conversation
8de300c to
82a2629
Compare
* The original `qtraverse` wasn't powerful enough to implement `qfoldMapDefault`. Using an *indexed* applicative makes it so. * Add `qfoldMapDefault`. * Adjust the type of `traverse_` to match. * Remove the surprising `QFunctor` superclass of `QFoldable`. Closes morphismtech#10
Behold the power of `coerce`!
a966178 to
f216867
Compare
|
@echatav , here's my first little pull request. I have one or two more generalities to put in before I start porting things over from |
| qtraverse f (ProductQ p q) = ProductQ p `imap` f q | ||
| instance QTraversable IQ where qtraverse f (IQ c) = IQ `imap` f c | ||
|
|
||
| newtype QReverse t c x y = QReverse {getQReverse :: t (OpQ c) y x} |
There was a problem hiding this comment.
This looks isomorphic to ApQ t c x y since (OpQ c) y x is isomorphic to c x y, so seems redundant
There was a problem hiding this comment.
Redundant how? The basic idea is that it's possible to implement, say, a queue that enqueues on the left and dequeues on the right by wrapping the more usual version in QReverse. How do you propose to do it?
There was a problem hiding this comment.
Okay, I guess it can always be done using IxBackwards directly. I just stole the idea from Data.Functor.Reverse. I guess it's at least a useful demonstration of IxBackwards?
There was a problem hiding this comment.
I got the isomorphism wrong, it's not ApQ, it's OpQ (t (OpQ c)). It's interesting because you could use it in reversePath to change the signature from
reversePath :: (QFoldable c, CFree path) => c p x y -> path (OpQ p) y xto
reversePath :: (QFoldable c, CFree path) => c p x y -> ReverseQ path p x yI haven't given thought to how to port queues since I never needed them :-/
qtraversewasn't powerful enough to implementqfoldMapDefault. Using an indexed applicative makes it so.qfoldMapDefault.traverse_to match.QFunctorsuperclass ofQFoldable.Closes #10