[Haskell-cafe] Partial instance of a class

[Rick Owens]

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 at 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* <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
>
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180226/417ac71d/attachment.html>