Wolfgang Jeltsch wrote:
| Now, I have a type which would fit wonderfully into
| the Arrow concept if arrows wouldn't be expected to
| have a first operator.
Ashley Yakeley replied:
| ...then it's not an Arrow.
Might I remind you that an arrow (as defined in category
theory) only requires identy and composition to be defined
and satisfying some laws?
In particular, an arrow does not have to have the operations
"arr" and "first".
There are many types which would fit nicely in an arrow
framework, but do not because of the demand of these
operators, here are two examples:
* Isomorphisms, are nice arrows:
type Iso a b = (a -> b, b -> a)
but of course not all functions have an appropriate
inverse, so arr cannot be defined.
* Stream processors (from Fudgets) are nice arrows:
data SP a b = Get (a -> SP a b) | Put a (SP a b) | Nil
But the first operator assumes that the product type
associated with this arrow must be Haskell's product
(,), but in fact a sum type would make a much nicer
product.
The reason why John chose to lay out the arrow library as it
is (I think) is because of:
* Simplicity; if you are too general then you get lots of
painful classes all over the place.
* Sufficiency; all examples he considered in his paper fit
into the current framework.
It is not clear if the design of the arrow library should be
redone just because some particular examples do not fit in.
After all, there are many examples of monads (Sets for
example) which can not be made instance of the current monad
class in Haskell.
Regards,
/Koen.
--
Koen Claessen
http://www.cs.chalmers.se/~koen
Chalmers University, Gothenburg, Sweden.
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
