<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Not taken personally, don't worry. You've done enough picking up
where I've failed to get work done over the years, too!</p>
<p>I'm trying to be deliberate about "this does raise this issue but
it isn't a blocker and can be separated out" pretty much precisely
so I can be cheerfully ignored if nobody else cares.</p>
<p>I may have tweeted some minor irritation about how when it comes
to my code, ApplicativeDo fails to give a, er, *> though :)</p>
<p><$ could reasonably be rebound to |- in some of my code, and
the main reason I don't is I'm using it to implement a type system
which has its own turnstile. Which I'm pretty sure I told you
years ago, but it may be mildly new to others here.<br>
</p>
<div class="moz-cite-prefix">On 18/12/2018 15:15, Cale Gibbard
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF3RzK_xJ+6o-KdiaQoSn3bDUedCqd=7=6RECNy-2F1UjhQydA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">Haskell-prime@haskell.org</a><br>
> <a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">Haskell-prime@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>