[Haskell-cafe] arrow notation

[Ross Paterson]

On Mon, Feb 11, 2013 at 12:27:15AM +0100, Ertugrul Söylemez wrote:
> I'm making heavy use of arrow notation, so I'd like to propose a set of
> small improvements, not only syntactical.
> 
> ## Ignored input values
> 
> Many computations ignore their input value.  You can recognize them by
> their type:  If the input type is fully polymorphic and the output type
> is unrelated, the computation cannot use its input value.  In that case
> it would make sense to just pass whatever is the cheapest thing you
> could pass without requiring me to spell it out:
> 
>     comp1 :: Arr a Int
>     comp2 :: Arr a Double
> 
> Before:
> 
>     proc x1 -> do
>         x2 <- comp1 -< x1
>         x3 <- comp2 -< x2
>         id -< (x2, x3)
> 
> After:
> 
>     proc _ -> do
>         x1 <- comp1
>         x2 <- comp2
>         id -< (x1, x2)
> 
> Then the arrow notation compiler could just pass whatever is most
> convenient at that spot.  In this case it would just compose with
> '&&&':
> 
>     comp1 &&& comp2

Inspection of types is not allowed with GHC's constraint-based
type checker, which rules out things like this.

> ## returnA
> 
> We don't need it anymore, and it has quite a stupid definition.  Get rid
> of it in favor of 'id'.

It would be reasonable to redefine returnA = id

> ## Operators
> 
> I often need to mix regular arguments with computation arguments in
> banana notation:
> 
>     let f c = f' x y c z
>     (| f (comp -< v) |)

This wouldn't be legal if f was defined inside the proc.  If the arguments
come from outside the proc, you could write (permuting the arguments)

     (| (f x y z) (comp -< v) |)

If they're defined inside the proc, you'd have something like

     (| f (comp -< v) |) x y z

> ## PreArrow
> 
> All sensible arrows form a family of functors:
> 
>     instance (Arrow a) => Functor (a b) where
>         fmap f = (arr f .)
> 
> But they do more:  Every arrow is a profunctor as defined in the
> 'profunctors' package:
> 
>     instance (Arrow a) => Profunctor a where
>         lmap f = (. arr f)
>         rmap = fmap
> 
> That's just what you called PreArrow,

Not so: every arrow has lmap and rmap, but not everything that has an
lmap also has an rmap.

> ## Applicative
> 
> One of the main bottlenecks of arrows is the heavy tuple handling, but
> most (if not all) arrows form a family of applicative functors.  I
> noticed a huge speedup by moving from arrow style to applicative style
> where possible:
> 
>     liftA2 (+) (lmap f c) (fmap g d)
> 
> is often much faster than:
> 
>     arr (uncurry (+)) . (c . arr f &&& arr g . d)
> 
> Besides being more readable it sometimes improved the performance of my
> code by an order of magnitude.  So perhaps check to see if the category
> forms an applicative functor.  If it does, you can get along without
> Arrow entirely.
> 
> In fact I propose to generalize all the Arrow* classes to Category*
> classes.

That sounds reasonable.  It's convenient to use simpler classes instead
of Arrow where possible, but it's not always possible.