I would also like to register interest in what the community thinks about this problem, and add a couple of more motivating examples that I face regularly in my work:

1) `Bounded`, for things that have a minBound but no maxBound (like String). I often resort to Default in this case to avoid the use of `error`, but am unhappy with this because it doesn't "mean" the same thing, nor can it use derived combinators, as Jeroen mentions.

2) `Enum`, when used with types with more than 2^64 values (i.e. a sha-256 derived "keyspace", with 2^256 values). The `fromEnum` documentation claims "It is implementation-dependent what fromEnum returns when applied to a value that is too large to fit in an Int", but since approximately zero percent of 2^256 values will fit in an Int, I typically resort to `error` for all cases just to make it clear that toEnum/fromEnum are not going to work for any meaningful fraction of possible values.

Thanks!

-Rick

On Mon, Feb 26, 2018 at 11:36 AM, MarLinn <monkleyon@gmail.com> wrote:

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 library. For the latter, maybe the subhask prelude, but more likely the 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

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.