From carter.schonwald at gmail.com Mon Dec 3 21:23:52 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 3 Dec 2018 16:23:52 -0500 Subject: Helium II In-Reply-To: References: Message-ID: i'm slowly prepping some stuff for ghc and the committee, though i can't say about the general action. I do think some stuff i've got planned should make its way in, i cant speak for other folks etc etc On Fri, Nov 30, 2018 at 5:54 AM Anthony Clayden < anthony_clayden at clear.net.nz> wrote: > On *Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:* > > > >* Frankly after you've filtered out all that, I'd be astonished if you** > have anything left. It seems to be usual practice on Hackage to switch** > on a swag of LANGUAGE pragmas even if this module isn't using them.* > > >>* (MPTCs, FlexibleInstances/Contexts in particular.)* > > > A depressing remark, which comes close to saying > > there is no true Haskell. > > ? There wasn't a true Haskell in 1998. Already Hugs (in HugsMode) and GHC (with glasgow-extns) had MPTCs, FlexibleInstances/Contexts, FunDeps, UndecidableInstances. Overlapping instances was optional extra. > > > It's one reason I hang mostly with Hugs. > > Interesting. Does that mean Hugs98? How on earth do you manage without at least some of the above? > > > GHC pretty well repudiates Haskell 2010. > > So does Hugs (in HugsMode): a large proportion of the extra features in H2010 were suggested by the Hugs teams; and Hugs 2006 was already far advanced beyond it. > > > > May Haskell 2020 receive more respect! > > I think you'll need to adjust your expectations: I doubt H2020 will happen. There was a glimmer of activity last month, but this list has resumed its moribund state. So I think we can put last month down to dead cat bounce. If H2020 does happen, HugsMode will still be well ahead of whatever gets added. > > > AntC > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flippa at flippac.org Mon Dec 3 21:48:59 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon, 3 Dec 2018 21:48:59 +0000 Subject: Helium II In-Reply-To: References: Message-ID: <88003ed0-c523-1a2e-419f-a5621feaffcb@flippac.org> Good to know! It's important to keep morale up and do what we can. I imagine that'll be small details in my case, but there's meaningful modernisation to be done even if major type system features are still too difficult to standardise just yet. On 03/12/2018 21:23, Carter Schonwald wrote: > i'm slowly prepping some stuff for ghc and the committee, though i > can't say about the general action. I do think some stuff i've got > planned should make its way in, i cant speak for other folks etc etc > > On Fri, Nov 30, 2018 at 5:54 AM Anthony Clayden > > > wrote: > > On /Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:/ > > > >/Frankly after you've filtered out all that, I'd be astonished > if you//have anything left. It seems to be usual practice on > Hackage to switch//on a swag of LANGUAGE pragmas even if this > module isn't using them./ > > >>/(MPTCs, FlexibleInstances/Contexts in particular.)/ > > A depressing remark, which comes close to saying > > there is no true Haskell. > ? There wasn't a true Haskell in 1998. Already Hugs (in HugsMode) > and GHC (with glasgow-extns) had MPTCs, > FlexibleInstances/Contexts, FunDeps, UndecidableInstances. > Overlapping instances was optional extra. > > It's one reasonI hang mostly with Hugs. > Interesting. Does that mean Hugs98? How on earth do you manage > without at least some of the above? > > GHC pretty well repudiates Haskell 2010. > So does Hugs (in HugsMode): a large proportion of the extra > features in H2010 were suggested by the Hugs teams; and Hugs 2006 > was already far advanced beyond it. > > May Haskell 2020 receive more respect! > I think you'll need to adjust your expectations: I doubt H2020 > will happen. There was a glimmer of activity last month, but this > list has resumed its moribund state. So I think we can put last > month down to dead cat bounce. If H2020 does happen, HugsMode will > still be well ahead of whatever gets added. > AntC > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime -------------- next part -------------- An HTML attachment was scrubbed... URL: From blamario at ciktel.net Sat Dec 15 23:46:15 2018 From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Sat, 15 Dec 2018 18:46:15 -0500 Subject: LAST CALL to comment on the Appicative/Monad Proposal Message-ID: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> 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. From blamario at ciktel.net Tue Dec 18 03:17:03 2018 From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Mon, 17 Dec 2018 22:17:03 -0500 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> Message-ID: While you're reviewing AMP, please take a bit of time to also comment on the related new MonadPlus excise proposal at https://github.com/haskell/rfcs/pull/23 The proposal is very short so it should be an easy decision. Thank you. On 2018-12-15 6:46 p.m., 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 > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From hvriedel at gmail.com Tue Dec 18 07:38:01 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 18 Dec 2018 08:38:01 +0100 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> Message-ID: Hello Mario et al., On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević wrote: > While you're reviewing AMP, please take a bit of time to also comment on > the related new MonadPlus excise proposal at > https://github.com/haskell/rfcs/pull/23 > > The proposal is very short so it should be an easy decision. Thank you. As I've explained already on the RFC, I refuse (i.e. to make this very clear: I'm exercising my veto) to accept the AMP change without also at least a commitment to MFP and MRP. And note that the committee was created with the explicit request from SPJ that it ought to be a consensus-based decision process rather than a democratic voting process -- and there isn't consensus in this matter as far as I'm concerned. The discussion started on the right foot with Richard rightly saying > The redundant functions (like return) are all well and good in an implementation such as GHC, but I think they should be struck from the Report. Let's design it like we should have from the beginning, cleanly. GHC could then include its non-conformance with this new standard as an infelicity. Perhaps GHC can even deprecate return, but I don't have a problem with just living with the infelicity. That's the ideal we should strive for and what I expected the discussion to follow-through but unfortunately it got lost along the way. Herbert From flippa at flippac.org Tue Dec 18 10:42:14 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue, 18 Dec 2018 10:42:14 +0000 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> Message-ID: <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> 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 > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From Henrik.Nilsson at nottingham.ac.uk Tue Dec 18 12:23:17 2018 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Tue, 18 Dec 2018 12:23:17 +0000 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> Message-ID: <5C18E6B5.1050604@exmail.nottingham.ac.uk> Hi all, Well, I am in favour of discussing AMP and MRP separately because: a) As far as I am aware, there is no compelling *technical* reason for not doing so. b) On balance, this is the path most likely to result in some progress on this issue. Of course, if there *is* a fundamental technical reason for why the AMP, MFP, and MRP all *must* be discussed together, then please put this forward. As to the underlying issue, I don't agree that AMP on its own somehow is not "clean". But of course, design is something where reasonable people may choose to disagree. (Which in itself strongly suggests that it makes sense to strive to consider technically independent proposals separately.) The rationale for my position is: a) The remaining legacy issues raised by MRP significantly outweighs any technical benefits. b) Keeping "return" as a monadic *method* would in principle (through a minor language extension that has been proposed separately for different reasons) allow both Functor and Applicative instances to be defined in terms of a Monad instance. The latter is really useful in a situation where one genuinely only cares about the monad, makes perfect sense mathematically of course, and would go a long way towards alleviating the genuine difficulties of teaching monads that AMP did bring about, as reported by a number of *very* experienced educators. But clearly this is a separate discussion. Which is why AMP, MRP, and MFP should be considered separately. One high-level perspective on this is the well-established possibility in Haskell of defining an instance of a class by only giving definitions of a subset of its methods where methods are interdefinable. Many methods in the Functor/Monad/Applicative hierarchy are similarly interdefinable, but spread over more than one class. But in principle, choosing to define e.g. "fmap" in terms of the monadic methods, or "pure" in terms of "return", or vice versa for that matter, is not very different from the choice between defining a monad in terms of bind or join. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From flippa at flippac.org Tue Dec 18 12:32:48 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue, 18 Dec 2018 12:32:48 +0000 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: <5C18E6B5.1050604@exmail.nottingham.ac.uk> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <5C18E6B5.1050604@exmail.nottingham.ac.uk> Message-ID: <4119f0ac-fe6b-6a67-0092-25a0dfe1bf69@flippac.org> On 18/12/2018 12:23, Henrik Nilsson wrote: > Hi all, > > Well, I am in favour of discussing AMP and MRP separately Whoops, my bad, wasn't familiar enough to realise my suggestion was effectively covered by MRP! I think it might be a legitimate thing to tease do-uses-*> apart from MRP-as-a-whole as it only affects do notation and is already justifiable in terms of AMP's rationale alone, but I'll entirely understand if it's a bigger can of worms than is worth it at this point. That said, if there's any appetite for it we could ask for the relevant toggles to be added to GHC and gather some data, possibly branching this off as an AMP-or-MRP thing? As I've said, I have a use case for it today and in the absence of other extensions or alterations. 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. From Henrik.Nilsson at nottingham.ac.uk Tue Dec 18 13:41:20 2018 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Tue, 18 Dec 2018 13:41:20 +0000 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: <4119f0ac-fe6b-6a67-0092-25a0dfe1bf69@flippac.org> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <5C18E6B5.1050604@exmail.nottingham.ac.uk> <4119f0ac-fe6b-6a67-0092-25a0dfe1bf69@flippac.org> Message-ID: <5C18F900.7080307@exmail.nottingham.ac.uk> 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. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From flippa at flippac.org Tue Dec 18 14:45:04 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue, 18 Dec 2018 14:45:04 +0000 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: <5C18F900.7080307@exmail.nottingham.ac.uk> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <5C18E6B5.1050604@exmail.nottingham.ac.uk> <4119f0ac-fe6b-6a67-0092-25a0dfe1bf69@flippac.org> <5C18F900.7080307@exmail.nottingham.ac.uk> Message-ID: 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 From cgibbard at gmail.com Tue Dec 18 14:52:50 2018 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue, 18 Dec 2018 09:52:50 -0500 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> Message-ID: 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, 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 > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flippa at flippac.org Tue Dec 18 15:07:09 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue, 18 Dec 2018 15:07:09 +0000 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> Message-ID: <76ed65ab-dfd3-c4c0-2a3b-d1a25c510fad@flippac.org> 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, > 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 > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Tue Dec 18 15:15:21 2018 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue, 18 Dec 2018 10:15:21 -0500 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: <76ed65ab-dfd3-c4c0-2a3b-d1a25c510fad@flippac.org> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> <76ed65ab-dfd3-c4c0-2a3b-d1a25c510fad@flippac.org> Message-ID: 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 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, 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 >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flippa at flippac.org Tue Dec 18 15:22:39 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue, 18 Dec 2018 15:22:39 +0000 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> <76ed65ab-dfd3-c4c0-2a3b-d1a25c510fad@flippac.org> Message-ID: 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 > 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, >> > 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 >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> _______________________________________________ >> Haskell-prime mailing list >> Haskell-prime at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From flippa at flippac.org Tue Dec 18 16:05:24 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue, 18 Dec 2018 16:05:24 +0000 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <5C18E6B5.1050604@exmail.nottingham.ac.uk> <4119f0ac-fe6b-6a67-0092-25a0dfe1bf69@flippac.org> <5C18F900.7080307@exmail.nottingham.ac.uk> Message-ID: <3d89f068-0e47-3a12-01ec-ef341209be7e@flippac.org> 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From Henrik.Nilsson at nottingham.ac.uk Tue Dec 18 18:02:25 2018 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Tue, 18 Dec 2018 18:02:25 +0000 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> Message-ID: <5C193631.2050001@exmail.nottingham.ac.uk> Hi, On 12/18/2018 02:52 PM, Cale Gibbard wrote: > 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). I personally fully agree with this sentiment: I do find the use of "pure" vs. "return" to be a very useful signal to the reader. Moreover, while there is little risk of confusion when arrow syntax is used, looking just at names, the fact is that the use of the distinct "returnA" also sends a similar signal to the reader, and consequently there is a certain consistency in distinct names being used for the three different computational notions for which (variations of) do-notation is provided. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From mblazevic at stilo.com Tue Dec 18 21:40:56 2018 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Tue, 18 Dec 2018 16:40:56 -0500 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> Message-ID: On 2018-12-18 2:38 a.m., Herbert Valerio Riedel wrote: > Hello Mario et al., > > On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević wrote: >> While you're reviewing AMP, please take a bit of time to also comment on >> the related new MonadPlus excise proposal at >> https://github.com/haskell/rfcs/pull/23 >> >> The proposal is very short so it should be an easy decision. Thank you. > > As I've explained already on the RFC, I refuse (i.e. to make this very > clear: I'm exercising my veto) to accept the AMP change without also > at least a commitment to MFP and MRP. And note that the committee was > created with the explicit request from SPJ that it ought to be a > consensus-based decision process rather than a democratic voting > process -- and there isn't consensus in this matter as far as I'm > concerned. What exactly would you consider "a commitment to MFP and MRP"? As for myself, they are both on my to-do list. I just don't want to get lost in endless discussions without having anything done, so I performed the first step, the AMP. If that is accepted, I fully intend to prepare both MFP and MRP proposals - unless somebody else does it first. Is that commitment enough? From doug at cs.dartmouth.edu Wed Dec 19 00:25:42 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 18 Dec 2018 19:25:42 -0500 Subject: LAST CALL to comment on the Appicative/Monad Proposal Message-ID: <201812190025.wBJ0PguA050886@tahoe.cs.Dartmouth.EDU> I am very glad to see Applicative take its place in the report: one less mystery in understanding Haskell in the wild. The following comments pertain to presentation. 13.1 Functor class "The Functor class is used for types that can be mapped over." "is used for" is extremely vague. Better wording would be "The functor class comprises types that can be mapped over." The same comment applies to section 6.3.5. 13.2 Applicative class A verbal hint about the mnemonic intent of liftA2, like those for liftA and liftA3 in 13.4, would be helpful. Why is the "methods" subsection empty? 13.3 Alternative class This class hasn't been fully integrated into the report. It is missing from the Standard Prelude (Section 9) and from its natural place after 6.3.6. <|> appears here without definition and is not in the index. Why is the "methods" subsection empty? Doug McIlroy From blamario at ciktel.net Wed Dec 19 03:44:41 2018 From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Tue, 18 Dec 2018 22:44:41 -0500 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: <201812190025.wBJ0PguA050886@tahoe.cs.Dartmouth.EDU> References: <201812190025.wBJ0PguA050886@tahoe.cs.Dartmouth.EDU> Message-ID: <560a93f6-3f26-41f7-2154-6844b9779b6c@ciktel.net> On 2018-12-18 7:25 p.m., Doug McIlroy wrote: > I am very glad to see Applicative take its place in the > report: one less mystery in understanding Haskell in the > wild. The following comments pertain to presentation. Thank you for the comments. I will act on them if we end up accepting the proposal. > 13.1 Functor class > > "The Functor class is used for types that can be mapped over." > > "is used for" is extremely vague. Better wording would be > "The functor class comprises types that can be mapped over." > > The same comment applies to section 6.3.5.     This was the wording in Haskell 2010, so I left it in place. I agree that this is a good time to improve it. > 13.2 Applicative class > > A verbal hint about the mnemonic intent of liftA2, > like those for liftA and liftA3 in 13.4, would be helpful. > > Why is the "methods" subsection empty?     Huh, good catch. I copied the output of Haddock into the TeX file, I don't know why the methods are missing. I'll have to examine the Haddock output more closely. > 13.3 Alternative class > > This class hasn't been fully integrated into the report. > > It is missing from the Standard Prelude (Section 9) > and from its natural place after 6.3.6.     This was intentional: the proposal is about Applicative, not about Alternative. I have added the Alternative class definition to the non-normative Control.Applicative module only to parallel the MonadPlus definition in the Control.Monad module. Note that Prelude contains no trace of MonadPlus either.     If the present proposal is accepted (with the other repairs you suggested), we'll next have a choice to make regarding Alternative. We can leave it in its present non-normative state, we can add it to Prelude in its full glory, or we can completely excise it from the report. I don't have a strong opinion here, but I dislike the first option and I have a weak preference for the last one. I'd mete the same treatment to MonadPlus, in this case with more conviction, and I've created an RFC for it. > <|> appears here without definition and is not in the index. > > Why is the "methods" subsection empty? > > Doug McIlroy > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From flippa at flippac.org Wed Dec 19 09:38:21 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed, 19 Dec 2018 09:38:21 +0000 Subject: LAST CALL to comment on the Applicative/Monad Proposal In-Reply-To: References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> Message-ID: On 18/12/2018 07:38, Herbert Valerio Riedel wrote: > Hello Mario et al., > > On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević wrote: >> While you're reviewing AMP, please take a bit of time to also comment on >> the related new MonadPlus excise proposal at >> https://github.com/haskell/rfcs/pull/23 >> >> The proposal is very short so it should be an easy decision. Thank you. > As I've explained already on the RFC, I refuse (i.e. to make this very > clear: I'm exercising my veto) to accept the AMP change without also > at least a commitment to MFP and MRP. And note that the committee was > created with the explicit request from SPJ that it ought to be a > consensus-based decision process rather than a democratic voting > process -- and there isn't consensus in this matter as far as I'm > concerned. To be clear: you would prefer the Report's status quo to AMP without MFP and MRP? Because that looks likely to be where we're headed unless we wait out GHC implementing both and see if everyone is resigned to that result. From flippa at flippac.org Thu Dec 20 09:25:14 2018 From: flippa at flippac.org (Philippa Cowderoy) Date: Thu, 20 Dec 2018 09:25:14 +0000 Subject: LAST CALL to comment on the Appicative/Monad Proposal In-Reply-To: <5C193631.2050001@exmail.nottingham.ac.uk> References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net> <52bf5bf6-494c-c043-ced3-2f0dbc895842@flippac.org> <5C193631.2050001@exmail.nottingham.ac.uk> Message-ID: <9ccaf345-9698-a6db-c0d1-5ae9a9a60c76@flippac.org> On 18/12/2018 18:02, Henrik Nilsson wrote: > Moreover, while there is little risk of confusion when arrow > syntax is used, looking just at names, the fact is that the use of the > distinct "returnA" also sends a similar signal to the reader, and > consequently there is a certain consistency in distinct names being > used for the three different computational notions for which > (variations of) do-notation is provided. > I'm reminded that once upon a time I suggested what we now call ApplicativeDo start off with its own keyword for specifically Applicative code and that what it now tries to do might be possible! The lexical bikeshedding doesn't strike me as fun though.