On Mon, Feb 26, 2018 at 06:36:27PM +0100, MarLinn wrote:
I've got some type X which is almost an Arrow, except that I cannot lift any function a -> b to my type (of course I can for some a and b), so I cannot give a sensible implementation for arr. I can however give sensible implementations for the other methods in the Arrow class, and I'd like to use them (and possibly derived combinators) in other places.
[...]
... I've seen this exact problem mentioned several times. Many nice things are almost arrows without an arr. But the arrow machinery pre-dates our current hierarchies and understanding, and it's never really been revised.
There's a myth floating around that "Arrow is much less useful because it forces you to implement arr". In fact, Arrow without arr would be as useless as Applicative without fmap. In almost all situations where you are stymied by arr a small redesign will solve the whole problem. In fact, you need to get into the realm of linear-types-like things before arr is too much (and even then a *linear* arr would be fine). I designed a library for constructing Postgres queries and it uses an Arrow interface. https://hackage.haskell.org/package/opaleye-0.5.3.0/docs/Opaleye-Internal-Qu... Naturally there is no way to run an arbitrary Haskell function "in the database". This is not an impediment because everything that the database acts on inside the arrow type (QueryArr) is wrapped in an abstract type (Column). This means the only way that arbitrary Haskell functions can be used inside the arrow is as a sort of "partial compilation". There is, in effect, a staging restriction. Haskell functions a -> b run at "query compile time" and Postgres functions run at "query run time". This observation was made in an ICFP '13 paper in the context of our beloved monads so nothing that I'm saying here is particular to those inscrutable arrows. http://www.cse.chalmers.se/~joels/writing/bb.pdf I would be sad to think that Haskell programmers are avoiding using Arrow because of this myth[1]. If Jeroen Bransen or anyone else would like more details about this approach please get in touch either via this list or personally. I'm happy to help out. Tom [1] On the other hand, avoiding using Arrow because the type in question is actually a Monad is a perfectly good reason.