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,
<fli...@flippac.org <mailto:fli...@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@haskell.org <mailto:Haskell-prime@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org <mailto:Haskell-prime@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
