[Haskell-cafe] Partial instance of a class

[Tom Ellis]

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-QueryArr.html

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.