2013/2/11 Ertugrul Söylemez <es@ertes.de>

Petr Pudlák <petr.mvd@gmail.com> wrote:

> class Arrow a => ArrowDelay a where
> delay :: a b c -> a () (b -> c)
>

> force :: Arrow a => a () (b -> c) -> a b c
>

> Perhaps it would be convenient to have ArrowDelay and the
> corresponding conversions included in the library so that defining and
> using Applicative instances for arrows would become more
> straightforward.

I appreciate the idea from a theoretical standpoint, but you don't
actually have to define an ArrowDelay instance for the notation to work.
The compiler can't check the laws anyway.

That's true. But I'm afraid that without the ArrowDelay constraint people would think that every arrow forms an applicative functor and eventually get into hard-to-trace problems with failing the applicative laws.

The compiler can't check the laws, so somebody else has to. Should it be users of an arrow or its authors?

Without the constraint, the burden would be on the users: "Before using the applicative instance, check if the arrow is really an applicative functor". That's something users of a library aren't supposed to do."

With the constraint, the burden would be on the authors of the arrow - they'd have to define the instance and be responsible for satisfying the laws. I feel this is more appropriate.

Best regards,

Petr Pudlak