[Haskell-cafe] Partial instance of a class

Jeroen Bransen jeroen at chordify.net
Tue Feb 27 10:38:21 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.
>
Perfect. In my concrete case I think a profunctor is indeed the thing I 
was looking for, and based on the other replies it seems that in general 
there are usually other classes that do match the set of functions you'd 
like. This of course doesn't completely solve the problem of the desire 
to use certain combinators, but I do agree that using error to partially 
implement a class isn't satisfactory either, and is very likely to lead 
to more problems.

Jeroen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180227/d6424151/attachment.html>


More information about the Haskell-Cafe mailing list