I've added the gist of this to the relevant github thread. I've been
clear that I don't consider it a blocker for the proposals.
On 18/12/2018 14:45, Philippa Cowderoy wrote:
On 18/12/2018 13:41, Henrik Nilsson wrote:
Hi,
Philippa wrote:
> It's a lot easier to estimate ecosystem impact given a switch that'll
> find all the resulting errors and give everyone a chance to fail any
> tests.
Yes, a good point.
But just to be clear, the impact of some changes go well beyond what can
be assessed by looking at impact on an existing code base alone.
And that is one reason for why MRP has been, and remains, so
controversial.
Sure. I think the one conceptual shift do-uses-*> would create is that
do notation no longer (except in the degenerate tail case) always
brings a Monad constraint, instead it would bring Applicative unless
something is bound with <-. If I'm right then that's certainly a long
way short of MRP per se, which I'm not interested in discussing at
this point :)
I'm not sure how much of a problem that would create for teachers - I
imagine it depends very much on one's style, as it can even reinforce
the idea that Monad is partly about (unconstrained) binding! Which is
a plus if you like making the connection to ANF to some extent and
letting people think about a family of machine models. I think that's
something it might even be nice to let students play with in some
circumstances? Though I've done all my teaching 1:1 or with very small
groups myself and generally not to first year undergraduates. Nor have
I seen how AMP is affecting teaching in general properly.
Certainly something I'd be happy to talk about more if and when
there's time - realistically there's no good reason to hold up AMP
over this when it could be treated as a third proposal which depends
on AMP and which MRP mandates. Should I find a TLA for it?
Is there somewhere else I should be pasting my thoughts here to? Any
other comments? If I'm wasting people's time I'd rather stop, but if
this is a viable proposal refactoring that might be another matter.
Cheers,
Philippa
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
