Conal Elliott wrote:
While we're at it, how about one or more classes in between Category/Compositor and Arrow? One example is DeepArrow (see wiki page [1] and haddock docs [2]). Sample instances: functions and transformers of typed type representations, UIs, code, and pairs of same. I've currently structured DeepArrow as a subclass of Arrow, but most of my instances do not have arr. Any real arrow (including arr) is a DeepArrow (or almost), as the haddock docs mention.
It sounds like DeepArrow should be a superclass of Arrow. Could you give me a good example of a type that is DeepArrow but doesn't have arr?
DeepArrow could benefit from suggestions (perhaps refactoring), and I would appreciate such input. In any case, I imagine there's some rich, useful structure between Category & Arrow, and now would be a great time to explore it before settling on a new class hierarchy.
The only class that comes to mind is a subclass of Category that has arr but not first. But I don't know any instances that aren't Arrows. A full hierarchy might look something like this: class Category cat where id :: cat a a (.) :: cat b c -> cat a b -> cat a c class (Category arr) => PreArrow arr where arr :: (a -> b) -> arr a b class (PreArrow arr) => Arrow arr where arrAp :: arr a (b -> c) -> arr a b -> arr a c (&&&) :: arr a b -> arr a c -> arr a (b,c) class (PreArrow arr) => CoArrow arr where (|||) :: arr a c -> arr b c -> arr (Either a b) c class (Arrow arr,CoArrow arr) => ArrowChoice arr instance (Arrow arr,CoArrow arr) => ArrowChoice arr But I don't know of any useful types that are PreArrow but not Arrow, or CoArrow but not ArrowChoice. -- Ashley Yakeley