Tom Ellis | 22 Jun 14:23 2013
Picon

Best practices for Arrows?

I feel I may be doing a lot of programming with Arrows in the near future. 
Currently I'm delighted that Arrow notation[1] exists.  It makes using
Arrows much less painful.

Are there any best-practices I should be aware of with Arrows?  Or is it
just a case of getting on with it?

Tom

1.  http://www.haskell.org/ghc/docs/latest/html/users_guide/arrow-notation.html
Ertugrul Söylemez | 22 Jun 15:36 2013
Picon

Re: Best practices for Arrows?

Tom Ellis <tom-lists-haskell-cafe-2013 <at> jaguarpaw.co.uk> wrote:

> Are there any best-practices I should be aware of with Arrows?  Or is
> it just a case of getting on with it?

The best practice is probably to avoid them.  If your type is a monad,
there is little reason to use the awkward arrow interface.  In some
cases the arrow interface can improve the asymptotic performance though,
for example in the case of `Auto` (which is actually a monad, but the
monadic interface introduces a space leak).

In most cases when you expose an `Arrow` interface you can also expose a
`Category`+`Applicative` interface, which is pretty much equivalent
(except for a few extra laws):

    proc x -> do
        y1 <- a1 -< x
        y2 <- a2 -< x
        id -< x + y1 + y2^2

Is equivalent to:

    liftA3 (\x y1 y2 -> x + y1 + y2^2) id a1 a2

All arrows give rise to a [Profunctor] instance, so instead of `arr` you
can use `lmap` and `rmap`/`fmap`:

    arr f . c = fmap f c
    c . arr f = lmap f c

(Continue reading)

Tom Ellis | 22 Jun 20:05 2013
Picon

Re: Best practices for Arrows?

Hi Ertugul.  Thanks for taking the time to write me an in-depth reply!  I
have a few comments and a question.

On Sat, Jun 22, 2013 at 03:36:15PM +0200, Ertugrul Söylemez wrote:
> Tom Ellis <tom-lists-haskell-cafe-2013 <at> jaguarpaw.co.uk> wrote:
> 
> > Are there any best-practices I should be aware of with Arrows?  Or is
> > it just a case of getting on with it?
> 
> The best practice is probably to avoid them.  If your type is a monad,
> there is little reason to use the awkward arrow interface.

Unfortunately my type doesn't have a Monad instance.

> In most cases when you expose an `Arrow` interface you can also expose a
> `Category`+`Applicative` interface, which is pretty much equivalent
> (except for a few extra laws):
> 
>     proc x -> do
>         y1 <- a1 -< x
>         y2 <- a2 -< x
>         id -< x + y1 + y2^2
> 
> Is equivalent to:
> 
>     liftA3 (\x y1 y2 -> x + y1 + y2^2) id a1 a2

Yes, I can see how that would be useful.  My question is: are you talking
about this Applicative instance:

(Continue reading)

Ross Paterson | 22 Jun 23:24 2013
Picon

Re: Best practices for Arrows?

On Sat, Jun 22, 2013 at 07:05:09PM +0100, Tom Ellis wrote:
> On Sat, Jun 22, 2013 at 03:36:15PM +0200, Ertugrul Söylemez wrote:
> > If the interface is not under your control, make yourself comfortable
> > with the complete arrow syntax, most notably how it handles operators,
> > combinators and the `(| banana bracket notation |)`.  This is very
> > valuable information.
> 
> Interesting.  I hadn't noticed the `(| banana bracket notation |)` on the
> GHC Arrows page[1] before, but just saw it when I went back to check.

The banana brackets can be handy when you have operations on your arrow
type beyond the ones in Arrow and ArrowLoop.  But beware that the types of
the operations you can use with it will be changing in the next release
of GHC.  The change is the first one described on

http://hackage.haskell.org/trac/ghc/wiki/ArrowNotation
Tom Ellis | 13 Nov 20:09 2013
Picon

Re: Best practices for Arrows?

On Sat, Jun 22, 2013 at 10:24:23PM +0100, Ross Paterson wrote:
> On Sat, Jun 22, 2013 at 07:05:09PM +0100, Tom Ellis wrote:
> > On Sat, Jun 22, 2013 at 03:36:15PM +0200, Ertugrul Söylemez wrote:
> > > If the interface is not under your control, make yourself comfortable
> > > with the complete arrow syntax, most notably how it handles operators,
> > > combinators and the `(| banana bracket notation |)`.  This is very
> > > valuable information.
> > 
> > Interesting.  I hadn't noticed the `(| banana bracket notation |)` on the
> > GHC Arrows page[1] before, but just saw it when I went back to check.
> 
> The banana brackets can be handy when you have operations on your arrow
> type beyond the ones in Arrow and ArrowLoop.  But beware that the types of
> the operations you can use with it will be changing in the next release
> of GHC.  The change is the first one described on
> 
> http://hackage.haskell.org/trac/ghc/wiki/ArrowNotation

Is there any example of using Arrow banana brackets?  I downloaded all of
Hackage and grepped it, and the only usage was in the comments of
Control.Arrow.Internals!

I have feeling these might be useful to me, but I can't quite understand how
they work.

Tom
Ertugrul Söylemez | 23 Jun 09:14 2013
Picon

Re: Best practices for Arrows?

Tom Ellis <tom-lists-haskell-cafe-2013 <at> jaguarpaw.co.uk> wrote:

> Unfortunately my type doesn't have a Monad instance.

If you could reveal the type, we could give more precise suggestions.

> > In most cases when you expose an `Arrow` interface you can also
> > expose a `Category`+`Applicative` interface, which is pretty much
> > equivalent (except for a few extra laws):
> >
> >     proc x -> do
> >         y1 <- a1 -< x
> >         y2 <- a2 -< x
> >         id -< x + y1 + y2^2
> >
> > Is equivalent to:
> >
> >     liftA3 (\x y1 y2 -> x + y1 + y2^2) id a1 a2
>
> Yes, I can see how that would be useful.  My question is: are you
> talking about this Applicative instance:
>
> data MyArr a b = ...
>
> instance Arrow MyArr where
>     ...
>
> instance Functor (MyArr a) where
>   fmap f = (arr f <<<)
>
(Continue reading)


Gmane