[Haskell-cafe] Arrows: definition of pure & arr

[Jonathan Cast]

On 16 Feb 2008, at 11:40 PM, Peter Verswyvelen wrote:

> After having played with some packages that use arrows, and after  
> having read the very nice "programming with arrows" paper I wanted  
> to build some of my own.
>
> Strangely my code did not work, even the simplest function got  
> stuck in an infinite loop or gave a stack overflow.
>
> I quickly noticed I made a really stupid mistake, I forget to  
> implement "arr"! However, the compiler did not give a warning on  
> this. So I wandered how it was possible that the Arrow package had  
> a default implementation for something so specific as arr?
>
> The code revealed the following:
>
>  	-- | Lift a function to an arrow: you must define either this
> 	--   or 'pure'.
> 	arr :: (b -> c) -> a b c
> 	arr = pure
>
> 	-- | A synonym for 'arr': you must define one or other of them.
> 	pure :: (b -> c) -> a b c
> 	pure = arr
> Ah, so the default implementation of arr is pure... and vice versa...
>
> This feels like rather incorrect to me, but my feelings are based  
> on imperative background knowledge, so this might be totally  
> correct design in Haskell.
>
> Why not force people to implement arr and leave just pure as the  
> synonym? And if pure is really a synonym for arr, what does it do  
> inside the Arrow type class? Does it ever make sense to have a  
> different implementation for arr and pure?

No; the equations arr = pure and pure = arr are laws for the class.   
(This is true in general for default methods).

Note that this situation --- where leaving the default methods in  
place gives rise to an infinite loop --- is quite common; it occurs  
for the classes Eq and Ord, as well, for example.  This example is  
admittedly kind of silly, but I'm sure someone has a passionate  
attachment to one or both names, so requiring definitions to use one  
or the other would be controversial.

jcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080217/137a10cd/attachment-0001.htm