[Haskell-cafe] arr considered harmful

[Paterson, Ross]

Ryan Ingram writes:
> Most of the conversion from arrow syntax into arrows uses 'arr' to move components around. However, arr is totally opaque to the arrow itself, and prevents describing some very useful objects as arrows.

> For example, I would love to be able to use the arrow syntax to define objects of this type:

> data Circuit a b where
>     Const :: Bool -> Circuit () Bool
>     Wire :: Circuit a a
>     Delay :: Circuit a a
>     And :: Circuit (Bool,Bool) Bool
>     Or :: Circuit (Bool,Bool) Bool
>     Not :: Circuit Bool Bool
>     Then :: Circuit a b -> Circuit b c -> Circuit a c
>     Pair :: Circuit a c -> Circuit b d -> Circuit (a,b) (c,d)
>     First :: Circuit a b -> Circuit (a,c) (b,c)
>     Swap :: Circuit (a,b) (b,a)
>     AssocL :: Circuit ((a,b),c) (a,(b,c))
>     AssocR :: Circuit (a,(b,c)) ((a,b),c)
>     Loop :: Circuit (a,b) (a,c) -> Circuit b c
> etc.

> Then we can have code that examines this concrete data representation, converts it to VHDL, optimizes it, etc.

> However, due to the presence of the opaque 'arr', there's no way to make this type an arrow without adding an 'escape hatch'
>     Arr :: (a -> b) -> Circuit a b
> which breaks the abstraction: circuit is supposed to represent an actual boolean circuit; (Arr not) is not a valid circuit because we've lost the information about the existence of a 'Not' gate.

If you require the circuit to be parametric in the value types, you can limit the types of function you can pass to arr to simple plumbing.
See the netlist example at the end of my "Fun of Programming" slides (http://www.soi.city.ac.uk/~ross/papers/fop.html).