Arrows that are also Functors

Arrows that are also Functors

Is it common to make a type an instance of both Arrow and Functor type
class? If a type is both instance of Arrow and Functor, would you expect
that fmap = (^<<) ? If yes, how about adding this as expected law to the
Control.Arrow documentation? Same question for Applicative functors and
liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not
mention any Arrow law so far.)

Re: Arrows that are also Functors

On Tue, 2011-04-19 at 17:29 +0200, Henning Thielemann wrote:
> Is it common to make a type an instance of both Arrow and Functor type
> class? If a type is both instance of Arrow and Functor, would you expect
> that fmap = (^<<) ? If yes, how about adding this as expected law to the
> Control.Arrow documentation? Same question for Applicative functors and
> liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not
> mention any Arrow law so far.)

I believe reading in some paper/monad reader article that Arrow is
equivalent to Category that is Functor.

In any case iff there have been instances I would expect such things (I
believe both are true for (->)).

Re: Arrows that are also Functors

Is it common to make a type an instance of both Arrow and Functor type class? If a type is both instance of Arrow and Functor, would you expect that fmap = (^<<) ? If yes, how about adding this as expected law to the Control.Arrow documentation?

For any instance of Functor that is also an Arrow this must hold already given existing laws.

One (particularly obvious) arrow law is that

arr id = id

This law states the fact that arr is the Functor from the category of Haskell types to your arrow category.

Given that:

id ^<< g = arr id <<< g = g . arr id = g . id = g = id g

we can see (^<<) id = id is satisfied. The "second Functor law" comes for free given (^<<) id = id, and the free theorem for (^<<), so (^<<) is admissable as a definition for fmap.

Finally, valid Functor instances for a given type are unique.

This also follows from the free theorem for fmap and the side condition that fmap id = id and has been worked through here on the cafe before. I believe it was done most recently by Russell O'Connor.

So fmap = (^<<) must hold for any type that is both a valid instance of Arrow and Functor.

The free theorem for fmap does all your work for you and no new laws need to be placed on the books.

-Edward

Same question for Applicative functors and liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not mention any Arrow law so far.)

Is it common to make a type an instance of both Arrow and Functor type class? If a type is both instance of Arrow and Functor, would you expect that fmap = (^<<) ? If yes, how about adding this as expected law to the Control.Arrow documentation?

For any instance of Functor that is also an Arrow this must hold already given existing laws.

One (particularly obvious) arrow law is that

arr id = id

This law states the fact that arr is the Functor from the category of Haskell types to your arrow category.

Given that:

id ^<< g = arr id <<< g = g . arr id = g . id = g = id g

we can see (^<<) id = id is satisfied. The "second Functor law" comes for free given (^<<) id = id, and the free theorem for (^<<), so (^<<) is admissable as a definition for fmap.

Finally, valid Functor instances for a given type are unique.

This also follows from the free theorem for fmap and the side condition that fmap id = id and has been worked through here on the cafe before. I believe it was done most recently by Russell O'Connor.

So fmap = (^<<) must hold for any type that is both a valid instance of Arrow and Functor.

The free theorem for fmap does all your work for you and no new laws need to be placed on the books.

-Edward

Same question for Applicative functors and liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not mention any Arrow law so far.)

Re: Arrows that are also Functors

> On Tue, 2011-04-19 at 17:29 +0200, Henning Thielemann wrote:
> > Is it common to make a type an instance of both Arrow and Functor type
> > class? If a type is both instance of Arrow and Functor, would you expect
> > that fmap = (^<<) ? If yes, how about adding this as expected law to the
> > Control.Arrow documentation? Same question for Applicative functors and
> > liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not
> > mention any Arrow law so far.)
>
> I believe reading in some paper/monad reader article that Arrow is
> equivalent to Category that is Functor.

I think that is actually an Applicative Category (just a bit more power) valid
for all source types. The first I was exposed to this idea was Patai's blog.
If you know of another source, I would like to know as I've been working to
ensure the laws follow from the parametricity and write up a little summary.

Anyway, assuming the laws are all okay, the applicative side of it is
especially clear if you look at an alternative definition for applicative

This alternative definition puts emphasis on the fundamental operation of
pairwise ordering. The order aspect is usually a bit hidden by the fact that
(<*>) does it when sticking them into a closure.

f <*> x = fmap ap $ f `order` x
where ap (f,x) = f x

Thinking of the fundamental Applicative operation as ordering really reveals
why it (and Monad) is so useful for IO. An ordering combinator is the
critical element required for determinism in the face of side effects.

All the arrow stuff falls out pretty easy given this definition. Let ''' be
used to indicate the standard operations on underlying category.

Re: Arrows that are also Functors

On Tue, Apr 19, 2011 at 11:22:12PM -0400, Tyson Whitehead wrote:
> On April 19, 2011 12:22:39 Maciej Marcin Piechotka wrote:
> > I believe reading in some paper/monad reader article that Arrow is
> > equivalent to Category that is Functor.
>
> I think that is actually an Applicative Category (just a bit more power)
> valid for all source types. The first I was exposed to this idea was
> Patai's blog. If you know of another source, I would like to know
> as I've been working to ensure the laws follow from the parametricity
> and write up a little summary.

For the IO monad, for example, normal fix would give you an IO value which
would repeat the underlying IO action. The mfix' above give you the result of
the first run of the IO action lazily bound in an IO context. Consider

The difference between mfix and mfix' being you can't (or at least I couldn't)
implement it for non-singleton monads such as list. The problem was mfix had
to do a map like operation across the underlying structure to invoke the
function on the lazily bound singletons before any of the structure existed.

BTW haskellers, I've been wondering if mfix would better be defined as

mfix' :: (m a -> m a) -> m a

where "mfix' f = mfix (f . pure)" for the computational monads. The advantage
being you can give a useful definition for structural monads as well.

Note: This does not generalize the signature of mfix, it only overlaps slightly, as not every monad m permits the extraction of the value a injected (consider Cont r), so you necessarily change the meaning or obliterate a number of instances.

Recall the main motivation for mfix was to support Erkoek and Launchbury's recursive do:

The other commonly proposed mfix replacement is to define it once, as guided by the types, but while this works for fix and the the comonadic equivalent, it doesn't generate a useful mfix for recursive do either.

Re: Arrows that are also Functors

On April 26, 2011 15:38:32 Maciej Piechotka wrote:
> I still cannot find any use which would not be covered by either mfix or
> fix.

You are correct. Perhaps I should have been clear that I wasn't meaning it in
the sense of anything new, but rather a "I noticed that this would unify the
interface so we wouldn't have to alternate between mfix and fix".

I wasn't meaning to propose it as something to immediately put, but rather was
just curious to have it discussed to learn what other people thought. In case
the interface was ever revised at some point in the future.

Re: Arrows that are also Functors

On April 26, 2011 15:19:53 Edward Kmett wrote:
> The other commonly proposed mfix replacement is to define it once, as
> guided by the types, but while this works for fix and the the comonadic
> equivalent, it doesn't generate a useful mfix for recursive do either.

Hi Edward,

Thanks for your input on this. I read the paper proposing mfix awhile back
(persumably this is Erkoek and Launchbury's one -- can't locate it right now).