[Haskell-cafe] Arrows: definition of pure & arr
jonathanccast at fastmail.fm
Sun Feb 17 03:00:43 EST 2008
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe