[Haskell-cafe] Partial instance of a class

MarLinn monkleyon at gmail.com
Mon Feb 26 17:36:27 UTC 2018


Hi,

> Is there any standard or guideline for making a "partial" instance of 
> a class, by which I mean implementing some methods of a class, but not 
> all of them? In my concrete case I've got some type X which is almost 
> an Arrow, except that I cannot lift any function a -> b to my type (of 
> course I can for some a and b), so I cannot give a sensible 
> implementation for arr. I can however give sensible implementations 
> for the other methods in the Arrow class, and I'd like to use them 
> (and possibly derived combinators) in other places.

this might not be the general answer you're looking for, but related to 
this special case:

Note that arrow syntax (both proc-do-notation and banana brackets) uses 
arr extensively under the hood. The same goes for many of the derived 
combinators. So you can not simply leave it out. But maybe there's no 
need to reinvent the wheel either. What you have probably is something 
like a /profunctor/ or a /braided category/, so you might be in luck 
finding some better suited library instead. For the former, probably the 
/profunctors/ <https://hackage.haskell.org/package/profunctors> library. 
For the latter, maybe the /subhask/ 
<https://github.com/mikeizbicki/subhask> prelude, but more likely the 
/categories/ <https://hackage.haskell.org/package/categories> library. 
If nothing else looking at them might help you better understand what 
structure you're dealing with. I personally don't use subhask, but the 
hierarchy diagrams and code snippets alone have been enlightening in the 
past. They might give you new search terms on the hunt for a better library.

Or maybe it's enough to make it an /Applicative/?

As a sidenote, I've seen this exact problem mentioned several times. 
Many nice things are almost arrows without an arr. But the arrow 
machinery pre-dates our current hierarchies and understanding, and it's 
never really been revised. From a more modern point of view there's 
little reason for its prominent place in base, except as an honorary 
member. There has also been discussion if/how the notation might be 
generalized. But it seems the pain was never strong enough, no one knows 
of a golden way forward, and there's always been ways around this. Oh well.

Cheers,
MarLinn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180226/00b9f384/attachment.html>


More information about the Haskell-Cafe mailing list