<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Let's not diverge too much on the nature of IO functions, in the
      context of this conversation, here are the functions that are
      partial:<br>
      <br>
      - head, tail, init, last, ...<br>
      - foldr1, foldl1, maximum, minimum, ...<br>
      - (!!)<br>
      <br>
      They all have in common the usage of `error(WithoutStackTrace)`,
      so we can safely say that 'partial ~ using
      error(WithoutStackTrace)'  in the context of this RFC. <br>
      <br>
      <br>
    </p>
    <div class="moz-cite-prefix">Le 09/06/2021 à 09:31, Julian Ospald a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:F76AC472-5D0F-4626-BFCB-D93B2486AAA3@posteo.de">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <title></title>
      <style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>Yeah,
      I think a typeclass to express partiality is a sloppy technique.
      I'm not even sure everyone agrees on what 'partial' means: if my
      function throws an IO error on relative FilePaths, is it partial?
      Is all IO partial?<br>
      <br>
      Haskell is definitely not a total language and I doubt it will be.
      I also don't think that it's an interesting goal. It requires a
      considerable shift in language design.<br>
      <br>
      HasCallstack sounds like a pragmatic solution, but you could as
      well create an alternative prelude that adds it everywhere you
      want and then avoid implicit prelude. That won't help you with
      unsound dependencies, that don't use it, but it's opt-in, which
      seems more reasonable given that it's obviously a somewhat
      controversial change.<br>
      <br>
      I'd expect the nay-sayers here, however, to be a driving force in
      a better GHC based solution. Otherwise, the next time this comes
      up people will say "you had time enough".<br>
      <br>
      <div class="gmail_quote">On June 8, 2021 6:10:52 PM UTC, Oliver
        Charles <a class="moz-txt-link-rfc2396E" href="mailto:ollie@ocharles.org.uk"><ollie@ocharles.org.uk></a> wrote:
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div><br>
          </div>
          <div><br>
          </div>
          <div>On Tue, 8 Jun 2021, at 6:36 PM, Richard Eisenberg wrote:<br>
          </div>
          <blockquote type="cite" id="qt"
            style="overflow-wrap:break-word;">
            <div>I've been very much of two minds in this debate: On the
              one hand, having these constraints is very practically
              useful. On the other, what we're doing here is very
              un-Haskellish, in that we're letting operational concerns
              leak into a declarative property (a function's type). The
              reason we're doing this is another un-Haskellish thing --
              partiality -- but that ship has sailed.<br>
            </div>
            <div class="qt-"><br>
            </div>
            <div class="qt-">So, may I propose a slightly different way
              forward?<br>
            </div>
            <div class="qt-"><br>
            </div>
            <div class="qt-">Instead of adding a HasCallStack constraint
              on these functions, add an IsPartial constraint. For
              example:<br>
            </div>
            <div class="qt-"><br>
            </div>
            <div class="qt-">> head :: IsPartial => [a] -> a<br>
            </div>
            <div class="qt-"><br>
            </div>
            <div class="qt-">This is slightly awkward, still, because
              IsPartial is a class-constraint-like-thing, but it has no
              parameter. But it has a few very nice properties:<br>
            </div>
            <div class="qt-">* IsPartial is declarative: it describes a
              property of the function without worrying about its
              operation.<br>
            </div>
            <div class="qt-">* If we think about the way constraints
              propagate, IsPartial has the right semantics: the caller
              of a partial function would itself become partial.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I don't think this is true.<br>
          </div>
          <div><br>
          </div>
          <div>Take:<br>
          </div>
          <div><br>
          </div>
          <div>foo :: Int -> Bool<br>
          </div>
          <div>foo _ = head [True]<br>
          </div>
          <div><br>
          </div>
          <div>Clearly foo is total - it is defined for all of its
            inputs. That it uses a partial function in its body isn't
            observable. So it's a shame that IsPartial leaks out.<br>
          </div>
          <div><br>
          </div>
          <div>I guess here you'd have me say<br>
          </div>
          <div><br>
          </div>
          <div>foo _ = partialityIsOk $ head [True]<br>
          </div>
          <div><br>
          </div>
          <div>?<br>
          </div>
          <div><br>
          </div>
          <div>Ollie<br>
          </div>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: <a class="moz-txt-link-freetext" href="https://glitchbra.in">https://glitchbra.in</a>
RUN: BSD</pre>
  </body>
</html>