[Haskell-cafe] Partial instance of a class

[Brandon Allbery]

I was under the impression most programmers avoid Arrows because they've
seen HXT. >.> Which really wants to be Applicative, not Arrow, so it's not
the best example of Arrows out there.

On Tue, Feb 27, 2018 at 5:52 AM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> 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.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180227/d473f40c/attachment-0001.html>