<div dir="ltr"><div>I guess I didn't mean to pick on your suggestion exactly -- the comments on the pull request triggered my remark even moreso, but I was on my phone and it was slightly easier to reply here.</div><div><br></div><div>Where I work, we've come to calling <$ "ice cream cone", so perhaps <* is "snow cone", lol.</div><div><br></div><div>It's definitely valuable to think about and discuss where the language might go, but every time I see that discussion in the context of producing the Haskell Report, I think about how H2010 went almost nowhere because of how this kind of discussion makes it easy to not decide on what any particular change to the Report might be, and sort of wish that we had a Report which was current at all...<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 18 Dec 2018 at 10:07 Philippa Cowderoy <<a href="mailto:flippa@flippac.org">flippa@flippac.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Getting to ditch a similar connotation in do notation is exactly
      why I've started this thread, of course! Some instances are far
      less about having pure/return, at least without some more powerful
      constructs we can't have in a standardised Haskell just yet. It's
      maybe a personal irritation that ApplicativeDo outright fails in
      that situation.<br>
    </p>
    <p>I was slightly appalled when I realised just now what
      pronunciations of *> and <* I could most easily justify if
      nobody else comes up with a suggestion - I think <* might be
      "klap".</p>
    <p>I do think there's value in wondering whether there are small
      changes to GHC we might request if nobody else does it. But that's
      partly because the Report has to be descriptive by default -
      otherwise there's no good institutional eye on neatening things up
      over time that has an eye on standards rather than the concerns
      that drive GHC.</p>
    <p>Fundamentally, if I'd wanted to drag up MRP rather than round off
      an edge, I would've done so explicitly! If someone wants to tell
      me where to nag the GHC folks I guess I might find the time. But
      I'm definitely looking at removing warts in the context of things
      that are already happening myself.<br>
    </p></div><div text="#000000" bgcolor="#FFFFFF">
    <div class="m_5314967535694380302moz-cite-prefix">On 18/12/2018 14:52, Cale Gibbard
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      Is it just me, or is all the discussion in these threads much more
      easily resolved if the Report is simply a report? Describe what
      is, rather than what you wish it was, and there's much less room
      for disagreement. A future Report can describe the way that these
      things work differently in the future when the changes actually
      happen in the implementation(s).
      <div><br>
      </div>
      <div>I don't know about anyone else, but at least from my
        perspective the value of the Report is in being valid
        documentation. The extent to which it fails to describe the
        actual family of languages we're presently writing code in is
        the extent to which it is failing to be a useful resource for
        our daily lives. </div>
      <div><br>
      </div>
      <div>I dunno, I feel kind of strange when people talk about
        removing 'return' for example, since it's very unlikely to go
        anywhere any time soon given how much code it is referenced in.
        It would be practically unreasonable even to try to deprecate
        it. Given that the Report is going to discuss this part of the
        language, it makes sense that it should be documented. </div>
      <div><br>
      </div>
      <div>Secondarily, it's a bit hard to describe why this is, but I
        personally find it a bit obnoxious whenever someone uses 'pure'
        rather than 'return' if the functor is known to be an instance
        of Monad and the generality isn't needed. It's a kind of signal
        that the code we're writing is (and perhaps needs to be)
        Applicative-polymorphic, or that we lack a Monad instance. So
        when I see it, I'm forced to consider for a moment why that
        might be, and whether I've understood the context incorrectly
        (and if it's not the case, that's sort of irritating).</div>
      <div><br>
      </div>
      <div>So when I see a suggestion to remove 'return' altogether it's
        sort of like "let's make everything mildly annoying to read
        forever" (by forcing this thought about exactly how general the
        code is, and making it slightly harder to guess the types at a
        glance).</div>
      <div><br>
      </div>
      <div>It's like while pure and return are equal whenever they would
        both typecheck, they've come to have very different connotations
        about the surrounding code. </div>
      <div><br>
        <div class="gmail_quote">
          <div dir="ltr">On Tue, Dec 18, 2018, 05:42 Philippa Cowderoy,
            <<a href="mailto:flippa@flippac.org" target="_blank">flippa@flippac.org</a>> wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm having
            a moment of fail trying to work out how to leave a comment.<br>
            <br>
            Is there a reason (other than GHC not doing it yet) not to
            have do <br>
            notation use *> instead of >> in line with using
            the least restrictive <br>
            function? I have some otherwise-nice logic programming code
            that would <br>
            actively benefit from it and it seems like a missing step
            from here.<br>
            <br>
            On 15/12/2018 23:46, Mario Blažević wrote:<br>
            > The very first RFC created (<a href="https://github.com/haskell/rfcs/pull/1" rel="noreferrer" target="_blank">https://github.com/haskell/rfcs/pull/1</a>),
            <br>
            > the Applicative/Monad Proposal, has now reached the
            Last Call stage. <br>
            > In order to ground the discussion, I have taken some
            time to update <br>
            > the Prelude and the text of the Haskell Report with its
            effects before <br>
            > the call. The rendered report is available at <br>
            > <a href="https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf" rel="noreferrer" target="_blank">https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf</a>
            <br>
            > for your review.<br>
            ><br>
            ><br>
            > TL;DR:<br>
            ><br>
            > The proposed changes to the report add the latest
            design of the <br>
            > Applicative and Alternative classes, but otherwise are
            intentionally <br>
            > minimal. Any further modifications, like the MonadFail
            proposal or <br>
            > moving return out of the Monad class, should be
            relegated to new RFCs.<br>
            ><br>
            ><br>
            > In some more detail, the changes are:<br>
            ><br>
            > 1. Applicative has been added as a subclass of Functor
            and superclass <br>
            > of Monad, its methods and laws as currently defined in
            the base <br>
            > library. The class and all its methods (pure,
            (<*>), (<*), (*>), and <br>
            > liftA2) are exported from Prelude, but no other
            Applicative-related <br>
            > functions (like liftA3) are.<br>
            ><br>
            > 2. The Functor class definition has been moved from
            module <br>
            > Control.Monad to Control.Applicative in order to avoid
            circular <br>
            > imports. Note that neither module is a part of the
            language <br>
            > specification.<br>
            ><br>
            > 3. The Monad class has been left unmodified, apart from
            making <br>
            > Applicative its superclass and adding  return a == pure
            a  as a law.<br>
            ><br>
            > 4. Alternative has been added to the
            Control.Applicative module, but <br>
            > not to Prelude. This is the same treatment already
            meted to MonadPlus. <br>
            > I'm unsure why MonadPlus even exists in the report, as
            it has no <br>
            > relevance to the language specification, and I would
            gladly remove <br>
            > both classes.<br>
            ><br>
            ><br>
            > Please take some time within the following three weeks
            (including some <br>
            > extra allowance for the upcoming holiday breaks) to
            vote for or <br>
            > against the proposal, or to leave a comment with
            suggestions for its <br>
            > improvement.<br>
            ><br>
            ><br>
            > _______________________________________________<br>
            > Haskell-prime mailing list<br>
            > <a href="mailto:Haskell-prime@haskell.org" target="_blank">Haskell-prime@haskell.org</a><br>
            > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
            _______________________________________________<br>
            Haskell-prime mailing list<br>
            <a href="mailto:Haskell-prime@haskell.org" target="_blank">Haskell-prime@haskell.org</a><br>
            <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
  </div></blockquote></div>