LAST CALL to comment on the Appicative/Monad Proposal
Philippa Cowderoy
flippa at flippac.org
Tue Dec 18 15:22:39 UTC 2018
Not taken personally, don't worry. You've done enough picking up where
I've failed to get work done over the years, too!
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.
I may have tweeted some minor irritation about how when it comes to my
code, ApplicativeDo fails to give a, er, *> though :)
<$ 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.
On 18/12/2018 15:15, Cale Gibbard wrote:
> 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.
>
> Where I work, we've come to calling <$ "ice cream cone", so perhaps <*
> is "snow cone", lol.
>
> 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...
>
> On Tue, 18 Dec 2018 at 10:07 Philippa Cowderoy <flippa at flippac.org
> <mailto:flippa at flippac.org>> wrote:
>
> 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.
>
> 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".
>
> 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.
>
> 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.
>
> On 18/12/2018 14:52, Cale Gibbard wrote:
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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).
>>
>> 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).
>>
>> 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.
>>
>> On Tue, Dec 18, 2018, 05:42 Philippa Cowderoy,
>> <flippa at flippac.org <mailto:flippa at flippac.org>> wrote:
>>
>> I'm having a moment of fail trying to work out how to leave a
>> comment.
>>
>> Is there a reason (other than GHC not doing it yet) not to
>> have do
>> notation use *> instead of >> in line with using the least
>> restrictive
>> function? I have some otherwise-nice logic programming code
>> that would
>> actively benefit from it and it seems like a missing step
>> from here.
>>
>> On 15/12/2018 23:46, Mario Blažević wrote:
>> > The very first RFC created
>> (https://github.com/haskell/rfcs/pull/1),
>> > the Applicative/Monad Proposal, has now reached the Last
>> Call stage.
>> > In order to ground the discussion, I have taken some time
>> to update
>> > the Prelude and the text of the Haskell Report with its
>> effects before
>> > the call. The rendered report is available at
>> >
>> https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf
>>
>> > for your review.
>> >
>> >
>> > TL;DR:
>> >
>> > The proposed changes to the report add the latest design of
>> the
>> > Applicative and Alternative classes, but otherwise are
>> intentionally
>> > minimal. Any further modifications, like the MonadFail
>> proposal or
>> > moving return out of the Monad class, should be relegated
>> to new RFCs.
>> >
>> >
>> > In some more detail, the changes are:
>> >
>> > 1. Applicative has been added as a subclass of Functor and
>> superclass
>> > of Monad, its methods and laws as currently defined in the
>> base
>> > library. The class and all its methods (pure, (<*>), (<*),
>> (*>), and
>> > liftA2) are exported from Prelude, but no other
>> Applicative-related
>> > functions (like liftA3) are.
>> >
>> > 2. The Functor class definition has been moved from module
>> > Control.Monad to Control.Applicative in order to avoid
>> circular
>> > imports. Note that neither module is a part of the language
>> > specification.
>> >
>> > 3. The Monad class has been left unmodified, apart from making
>> > Applicative its superclass and adding return a == pure a
>> as a law.
>> >
>> > 4. Alternative has been added to the Control.Applicative
>> module, but
>> > not to Prelude. This is the same treatment already meted to
>> MonadPlus.
>> > I'm unsure why MonadPlus even exists in the report, as it
>> has no
>> > relevance to the language specification, and I would gladly
>> remove
>> > both classes.
>> >
>> >
>> > Please take some time within the following three weeks
>> (including some
>> > extra allowance for the upcoming holiday breaks) to vote
>> for or
>> > against the proposal, or to leave a comment with
>> suggestions for its
>> > improvement.
>> >
>> >
>> > _______________________________________________
>> > Haskell-prime mailing list
>> > Haskell-prime at haskell.org <mailto:Haskell-prime at haskell.org>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org <mailto:Haskell-prime at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20181218/1f8c3d6a/attachment-0001.html>
More information about the Haskell-prime
mailing list