<div dir="ltr">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:<div><br></div><div>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.</div><br>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.<div><br></div><div>Thanks!</div><div><br></div><div>-Rick<br><div></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 26, 2018 at 11:36 AM, MarLinn <span dir="ltr"><<a href="mailto:monkleyon@gmail.com" target="_blank">monkleyon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Hi,<span class=""><br>
    <br>
    <blockquote type="cite">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.
      <br>
    </blockquote>
    <br>
    </span><p>this might not be the general answer you're looking for, but
      related to this special case:</p>
    <p>Note that arrow syntax (both proc-do-notation and banana
      brackets) uses <tt>arr</tt> 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 <i>profunctor</i>
      or a <i>braided category</i>, so you might be in luck finding
      some better suited library instead. For the former, probably the <a href="https://hackage.haskell.org/package/profunctors" target="_blank"><i>profunctors</i></a>
      library. For the latter, maybe the <a href="https://github.com/mikeizbicki/subhask" target="_blank"><i>subhask</i></a> prelude, but more
      likely the <a href="https://hackage.haskell.org/package/categories" target="_blank"><i>categories</i></a>
      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.<br>
    </p>
    <p>Or maybe it's enough to make it an <i>Applicative</i>?<br>
    </p>
    <p>As a sidenote, I've seen this exact problem mentioned several
      times. Many nice things are almost arrows without an <tt>arr</tt>.
      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 <tt>base</tt>, 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.</p>
    <p>Cheers,<br>
      MarLinn<br>
    </p>
    <br>
  </div>

<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>