<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>But nothing prevents us from agreeing on restricting the
      semantics of  `IsPartial` !<br>
      <br>
      We can write down in the Haddocks “`IsPartial` should exclusively
      be used for functions that use error/errorWithoutStackTrace, and
      not for imprecise exceptions or asynchronous exceptions.”<br>
      We have documentation, guides, tutorials, comments, style guides,
      etc. I just don't understand why it is a problem. And again, this
      is not a discussion that is unique to us.<br>
      The PureScript community have had their own Partial typeclass for
      ages and this hasn't triggered the end of the world. We don't have
      to delve into year-long arguments on The Nature of Partiality.</p>
    <p>--- rant ---<br>
      <br>
      As a general comment, it is honestly appalling how RFCs like that
      trigger such circlejerks that are so utterly disconnected from
      reality. This does not make us better as a community.<br>
      The last time I suggested a change in the base library
      (up-streaming strictness optimisations that were enabled at the
      first level of optimisation),<br>
      I've was told that this went against the spirit of the language,
      even though a simple look at the most minor optimisation level
      would reveal that we haven't been "true" to this "spirit" for a
      long, long time.<br>
      <br>
      And this is extremely bizarre since we try to take the highest
      moral stances on some topics whilst making dirty compromises on
      other topics (for which I am not seeing anyone actively try to
      change the status quo).<br>
      <br>
      > It's been well known for close to three decades(!) that it is
      perfectly
      <br>
      > possible to add sophisticated debugging support to lazy
      languages like
      <br>
      > Haskell without impacting on the language semantics or
      formulation of
      <br>
      > its libraries. The existing tracing and profiling mechanisms
      of GHC
      <br>
      > are examples of this.
      <br>
      <br>
      Henrik, Debug.Trace functions requires the use of
      "unsafePerformIO". Is this really the sort of thing we want to
      promote when we talk about "sophisticated debugging support to
      lazy languages without impacting the semantics"? <br>
      Looks like the semantics of pure functional programming are
      flushed down the toilets with that one.<br>
      <br>
      Regarding profiling, we are *unable* to teach how it works. The
      Haskell Wiki article¹ is a stub, there are issues² on the Cabal
      bug tracker to ask how to enable it, and for most people it's
      still a mystery. <br>
      <br>
      So before we say things like "It's been well known for close to
      three decades(!)(sic)", I suggest we get our shit together because
      right now we look like a bunch of clowns. And if by any chance the
      University of Nottingham has a secret vault of forbidden
      techniques regarding profiling Haskell applications, I'd love that
      the rest of the community could benefit from this 30yo knowledge,
      since apparently nothing has filtered and we are still like monkey
      playing with sticks in the outside world.<br>
      <br>
      So let's meditate on this a bit, shall we? As much as I am not the
      biggest fan of ad-hoc typeclasses to signal operational behaviour,
      the inability of the community to promote the "better" ways to
      handle such failure modes makes me think that we have no right to
      spit on this RFC. <br>
      <br>
      <br>
      ---<br>
      ¹ <a class="moz-txt-link-freetext" href="https://wiki.haskell.org/How_to_profile_a_Haskell_program">https://wiki.haskell.org/How_to_profile_a_Haskell_program</a><br>
      ² <a class="moz-txt-link-freetext" href="https://github.com/haskell/cabal/issues/5930">https://github.com/haskell/cabal/issues/5930</a><br>
    </p>
    <div class="moz-cite-prefix">Le 09/06/2021 à 09:57, Julian Ospald a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:59D4A825-D63B-4FF9-8819-EA816257066B@posteo.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      I'm aware what was meant, but this was in response to the proposed
      'IsPartial' typeclass, which will have this confusion pop up more
      often.<br>
      <br>
      <div class="gmail_quote">On June 9, 2021 7:48:58 AM UTC, "Hécate"
        <a class="moz-txt-link-rfc2396E" href="mailto:hecate@glitchbra.in"><hecate@glitchbra.in></a> wrote:
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <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"
                moz-do-not-send="true"><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" moz-do-not-send="true">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" moz-do-not-send="true">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" moz-do-not-send="true">https://glitchbra.in</a>
RUN: BSD</pre>
        </blockquote>
      </div>
    </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>