[Haskell-cafe] Best practices for Arrows?

[Ertugrul Söylemez]

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 <<<)
>
> instance Applicative (MyArr a) where
>   pure = arr . const
>   f <*> g = arr (uncurry ($)) <<< (f &&& g)

Yes, that seems right.


> I think I will be able to make my Arrow an ArrowLoop, but I haven't
> checked.

It's not that your type may have a useful or even sensible ArrowLoop
notion, but if it does, then arrow notation is very useful.  Also as
Ross noted it gives you access to some additional convenience syntax, in
particular if your type is an ArrowChoice.  Those combinators are
extremely awkward to use directly, but proc notation allows you to use
regular if/case syntax.

However, even then sometimes it can be beneficial to use composition of
small self-contained arrow formulas.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130623/d741d855/attachment.pgp>