From michael at snoyman.com Mon Nov 2 16:10:09 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 2 Nov 2015 08:10:09 -0800 Subject: process package with compilers besides GHC Message-ID: I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. * No pun intend -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Nov 2 18:13:06 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 2 Nov 2015 13:13:06 -0500 Subject: process package with compilers besides GHC In-Reply-To: References: Message-ID: I'd be (pleasantly) surprised to find any other compiler building with it. A couple of years back folks took an axe to similar untested and untestable legacy code paths in base. -Edward > On Nov 2, 2015, at 11:10 AM, Michael Snoyman wrote: > > I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: > > 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers > 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC > > I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. > > * No pun intend > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From rf at rufflewind.com Tue Nov 3 02:54:22 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Tue, 3 Nov 2015 10:54:22 +0800 Subject: [Haskell-cafe] process package with compilers besides GHC In-Reply-To: References: Message-ID: I too have wondered whether all the #ifdefs for hugs are necessary in 'directory'. From malcolm.wallace at me.com Tue Nov 3 10:55:51 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Tue, 03 Nov 2015 10:55:51 +0000 Subject: process package with compilers besides GHC In-Reply-To: References: Message-ID: <60D3E7AA-B977-4F36-8568-1E3ACE6F9767@me.com> Clean-up is generally good. I have not maintained any Haskell compiler for about 5 years now, so I think it is safe to say you can go ahead. nhc98 did indeed build the 'process' package as part of its library set, but most recently at version 1.0.1.4. Regards, Malcolm On 2 Nov 2015, at 16:21, Michael Snoyman wrote: > Forwarding directly to you, in case you're not reading the mailing lists. > > ---------- Forwarded message ---------- > From: Michael Snoyman > Date: Mon, Nov 2, 2015 at 8:10 AM > Subject: process package with compilers besides GHC > To: Haskell Cafe , libraries > > > I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: > > 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers > 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC > > I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. > > * No pun intend > From voldermort at hotmail.com Wed Nov 4 10:44:33 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 4 Nov 2015 03:44:33 -0700 (MST) Subject: Proposal: Dot as Postfix Function Apply Message-ID: <1446633873720-5821620.post@n5.nabble.com> Dot as Postfix Function Apply (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix) was originally part of ORF, but dropped to keep the scope/discussion more manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot postfix syntax. The idea is that instead of (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) we could have person.title ++ " " ++ person.firstName ++ " " ++ person.lastName This is a simple source-to-source translation with no changes to the type system (TDNR is an orthogonal proposal). The advantages are: 1. Code that's easier to read/write. 2. Familiar to users of almost every other programming language. 3. IDE auto-complete - an IDE can suggest functions applicable to the variable after typing . This would be an opt-in extension. I'm posting this to the libraries list because that's where proposals generally go, although this isn't strictly a library issue. If it should be on a different list I'll move it. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From alexander at plaimi.net Wed Nov 4 10:53:21 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Wed, 4 Nov 2015 11:53:21 +0100 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <5639E3A1.9090508@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I see this come up every now and again, and now, like always, I'm at a strong -1. First of all, I don't like magic built-in stuff. And this certainly is just that. It requires a higher precedence than you can possibly give in regular code, and it is an exception to how all other operators work with regards to requiring no spaces (note that this is different to "not requiring spaces") -- this is reserved for module namespaces per now. Furthermore, it's confusingly similar to regular functional composition. Second of all, we already have `x & f = f x`. Lastly, (and I don't want to argue this one too strongly) it is another thing like `return`, that makes imperative/OOP programmers confused. Semi-related, I'd be interested in proposing the inclusion of a new fixity level, 10, that was never used by base. *I* would certainly find it useful every now and again. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWOeOgAAoJENQqWdRUGk8B8PMQANQgXECx+FiFu5hpFGu1VAQ/ AUeLaDL9ZTdksRp17qxt59FQuieJ2Lx0fSCBjMYT1ZWvqivU9CRzlaJuHMcSpDen a3Te7aYBqpaUCRAfKrIjkx7HRneW/0ckkeyP9r3rxIOeTPdXMtqVoqmVzkuHUgKk 0N9+H2li6BirLj/w77y/x3+y2yK+rXuiCMFhZOp/frqhBo5uWQhM4fY5LAi5dcln lT8pjAWjjnBtyYIsZTFrKSF1GhEE/oAYr4C9EvL56yKNkuXBcbaaUNpwqnDEXVAW kcsAagiCCnfIC2ex/U7uyMixRGdV4ph853BP/8Rk6MG4WufJHNkV8glmDNjvI+5E H93PydpNtZwldCTawvidYPFQC1MO03HqThaND3wE5/zwjoiu4pdmx8oX5ZdYlmlx e7hUmr+trbVLi9cv/cBF6ewvtLQX0rLPljx0GuDawhTc17f+KK6WpmiOeCZcN9EF S4QA+9cB0Zxu2lwqu6s1wT9ss2Zt7DXlO/DDwV218+oCI+lKs1LdUEVDJptH8pbF XYr5K54jwfe5PxVHuZz6OwRbg/DtxEvynBljMuiFK2Fddf1W4TjZGFl3iT4x8LYk twD0hXwXpftH9Ew4JSli1XS//oqJ8auegP9mm6BhwscXbG/QuYpz1mqIrleY3+p0 2w8+2gu1JfQWUuQEXc2H =T3c6 -----END PGP SIGNATURE----- From voldermort at hotmail.com Wed Nov 4 11:06:19 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 4 Nov 2015 04:06:19 -0700 (MST) Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <5639E3A1.9090508@plaimi.net> References: <1446633873720-5821620.post@n5.nabble.com> <5639E3A1.9090508@plaimi.net> Message-ID: <1446635179475-5821623.post@n5.nabble.com> Alexander Berntsen wrote > First of all, I don't like magic built-in stuff. And this certainly is > just that. It requires a higher precedence than you can possibly give > in regular code, and it is an exception to how all other operators > work with regards to requiring no spaces (note that this is different > to "not requiring spaces") -- this is reserved for module namespaces > per now. Indeed, this is intended to be syntactically the same as dot-for-module-namespaces rather than an operator. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620p5821623.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From dominique.devriese at cs.kuleuven.be Wed Nov 4 14:16:23 2015 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Wed, 4 Nov 2015 15:16:23 +0100 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: +1 I'm convinced that this proposed extension would be extremely natural and practical if we give it a chance. The fact that it may conflict with previous, less natural syntax choices (lens composition with . comes to mind) should not be counted against an opt-in extension. Lens packages could easily provide an alternative notation for their . for when the extension is enabled. Regards, Dominique 2015-11-04 11:44 GMT+01:00 Jeremy : > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. > > The idea is that instead of > > (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) > > we could have > > person.title ++ " " ++ person.firstName ++ " " ++ person.lastName > > This is a simple source-to-source translation with no changes to the type > system (TDNR is an orthogonal proposal). The advantages are: > > 1. Code that's easier to read/write. > 2. Familiar to users of almost every other programming language. > 3. IDE auto-complete - an IDE can suggest functions applicable to the > variable after typing . > > This would be an opt-in extension. > > I'm posting this to the libraries list because that's where proposals > generally go, although this isn't strictly a library issue. If it should be > on a different list I'll move it. > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From johnw at newartisans.com Wed Nov 4 15:32:39 2015 From: johnw at newartisans.com (John Wiegley) Date: Wed, 04 Nov 2015 10:32:39 -0500 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> (Jeremy's message of "Wed, 4 Nov 2015 03:44:33 -0700 (MST)") References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: >>>>> Jeremy writes: > The idea is that instead of > (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) > we could have > person.title ++ " " ++ person.firstName ++ " " ++ person.lastName -1. "." means composition, not application. Is there a reason you can't use another operator name, as lens did with ^.? person^.title ++ " " ++ person^.firstName ++ " " ++ person^.lastName John From nikita at karetnikov.org Wed Nov 4 17:16:38 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Wed, 04 Nov 2015 20:16:38 +0300 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: (John Wiegley's message of "Wed, 04 Nov 2015 10:32:39 -0500") References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <87a8qtsn0p.fsf@karetnikov.org> Never voted on this list before, but now I just can't be silent: -1, folks already explained why. Let's not make yet another Python out of Haskell, there's enough already. =) From marcin.jan.mrotek at gmail.com Wed Nov 4 17:41:41 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 4 Nov 2015 18:41:41 +0100 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <87a8qtsn0p.fsf@karetnikov.org> References: <1446633873720-5821620.post@n5.nabble.com> <87a8qtsn0p.fsf@karetnikov.org> Message-ID: -1, making (foo.bar) =/= (foo . bar) seem plain evil to me. It's already bad enough that module namespace selection syntax clashes with function composition. Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From dluposchainsky at googlemail.com Wed Nov 4 17:46:21 2015 From: dluposchainsky at googlemail.com (David Luposchainsky) Date: Wed, 4 Nov 2015 18:46:21 +0100 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <563A446D.70405@gmail.com> On 04.11.2015 11:44, Jeremy wrote: > Dot as Postfix Function Apply -1 Magic syntax should enable magic features, this is just a grammar hack. Also there's Control.Arrow's >>> if you need LTR function composition. David/quchen From anfarmer at fb.com Wed Nov 4 18:28:08 2015 From: anfarmer at fb.com (Andrew Farmer) Date: Wed, 4 Nov 2015 18:28:08 +0000 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: I'm a strong -1. This already exists as an operator anyway: http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht ml#v:-38- On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese" wrote: >+1 > >I'm convinced that this proposed extension would be extremely natural >and practical if we give it a chance. The fact that it may conflict >with previous, less natural syntax choices (lens composition with . >comes to mind) should not be counted against an opt-in extension. >Lens packages could easily provide an alternative notation for their . >for when the extension is enabled. > >Regards, >Dominique > >2015-11-04 11:44 GMT+01:00 Jeremy : >> Dot as Postfix Function Apply >> >>(https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra >>c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5 >>VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG >>xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= ) >> was originally part of ORF, but dropped to keep the scope/discussion >>more >> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose >>dot >> postfix syntax. >> >> The idea is that instead of >> >> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) >> >> we could have >> >> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName >> >> This is a simple source-to-source translation with no changes to the >>type >> system (TDNR is an orthogonal proposal). The advantages are: >> >> 1. Code that's easier to read/write. >> 2. Familiar to users of almost every other programming language. >> 3. IDE auto-complete - an IDE can suggest functions applicable to the >> variable after typing . >> >> This would be an opt-in extension. >> >> I'm posting this to the libraries list because that's where proposals >> generally go, although this isn't strictly a library issue. If it >>should be >> on a different list I'll move it. >> >> >> >> -- >> View this message in context: >>https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na >>bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm >>l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH >>H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W >>70W4uY&e= >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> >>https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi- >>2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD >>0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t >>vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= >_______________________________________________ >Libraries mailing list >Libraries at haskell.org >https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2 >Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T >3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW >aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= From andrew.gibiansky at gmail.com Wed Nov 4 18:57:40 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Wed, 4 Nov 2015 10:57:40 -0800 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: I'm not on either side of this fence yet, but keep in mind that this can't just be done with an operator, because, if I understand the proposal correctly, the proposed dot hack would have a precedence *higher* than function application. That is, code like print person.name would desugar to print (name person) and not to name (print person) This is something that can't be replicated with current Haskell and is the crux of the issue, I think. As Chris Done said, "All of this because Haskellers are allergic to parentheses." (A true comment, if perhaps one I maybe don't agree with) -- Andrew On Wed, Nov 4, 2015 at 10:28 AM, Andrew Farmer wrote: > I'm a strong -1. This already exists as an operator anyway: > > http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht > ml#v:-38- > > > On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese" > dominique.devriese at cs.kuleuven.be> wrote: > > >+1 > > > >I'm convinced that this proposed extension would be extremely natural > >and practical if we give it a chance. The fact that it may conflict > >with previous, less natural syntax choices (lens composition with . > >comes to mind) should not be counted against an opt-in extension. > >Lens packages could easily provide an alternative notation for their . > >for when the extension is enabled. > > > >Regards, > >Dominique > > > >2015-11-04 11:44 GMT+01:00 Jeremy : > >> Dot as Postfix Function Apply > >> > >>( > https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra > >>c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5 > >>VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG > >>xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= ) > >> was originally part of ORF, but dropped to keep the scope/discussion > >>more > >> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose > >>dot > >> postfix syntax. > >> > >> The idea is that instead of > >> > >> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) > >> > >> we could have > >> > >> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName > >> > >> This is a simple source-to-source translation with no changes to the > >>type > >> system (TDNR is an orthogonal proposal). The advantages are: > >> > >> 1. Code that's easier to read/write. > >> 2. Familiar to users of almost every other programming language. > >> 3. IDE auto-complete - an IDE can suggest functions applicable to the > >> variable after typing . > >> > >> This would be an opt-in extension. > >> > >> I'm posting this to the libraries list because that's where proposals > >> generally go, although this isn't strictly a library issue. If it > >>should be > >> on a different list I'll move it. > >> > >> > >> > >> -- > >> View this message in context: > >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na > >>bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm > >>l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH > >>H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W > >>70W4uY&e= > >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> > >> > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi- > >>2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD > >>0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t > >>vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= > >_______________________________________________ > >Libraries mailing list > >Libraries at haskell.org > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2 > >Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T > >3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW > >aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Nov 4 19:31:01 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 4 Nov 2015 14:31:01 -0500 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: This has been proposed before and rejected before on many separate occasions. (.) already has a complicated enough role in our lives being used for qualified names as well as composition. Just.Just already doesn't parse as you'd expect due to its double-life. Giving it a third job breaks every f.g out there in user code and actively worsens systems that already exist for this purpose that compose better. I remain strongly in the -1 camp. -Edward On Wed, Nov 4, 2015 at 1:57 PM, Andrew Gibiansky wrote: > I'm not on either side of this fence yet, but keep in mind that this can't > just be done with an operator, because, if I understand the proposal > correctly, the proposed dot hack would have a precedence *higher* than > function application. > > That is, code like > > print person.name > > would desugar to > > print (name person) > > and not to > > name (print person) > > This is something that can't be replicated with current Haskell and is the > crux of the issue, I think. > > As Chris Done said, "All of this because Haskellers are allergic to > parentheses." (A true comment, if perhaps one I maybe don't agree with) > > -- Andrew > > On Wed, Nov 4, 2015 at 10:28 AM, Andrew Farmer wrote: > >> I'm a strong -1. This already exists as an operator anyway: >> >> >> http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht >> ml#v:-38- >> >> >> >> On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese" >> > dominique.devriese at cs.kuleuven.be> wrote: >> >> >+1 >> > >> >I'm convinced that this proposed extension would be extremely natural >> >and practical if we give it a chance. The fact that it may conflict >> >with previous, less natural syntax choices (lens composition with . >> >comes to mind) should not be counted against an opt-in extension. >> >Lens packages could easily provide an alternative notation for their . >> >for when the extension is enabled. >> > >> >Regards, >> >Dominique >> > >> >2015-11-04 11:44 GMT+01:00 Jeremy : >> >> Dot as Postfix Function Apply >> >> >> >>( >> https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra >> >> >>c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5 >> >> >>VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG >> >>xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= ) >> >> was originally part of ORF, but dropped to keep the scope/discussion >> >>more >> >> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose >> >>dot >> >> postfix syntax. >> >> >> >> The idea is that instead of >> >> >> >> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) >> >> >> >> we could have >> >> >> >> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName >> >> >> >> This is a simple source-to-source translation with no changes to the >> >>type >> >> system (TDNR is an orthogonal proposal). The advantages are: >> >> >> >> 1. Code that's easier to read/write. >> >> 2. Familiar to users of almost every other programming language. >> >> 3. IDE auto-complete - an IDE can suggest functions applicable to the >> >> variable after typing . >> >> >> >> This would be an opt-in extension. >> >> >> >> I'm posting this to the libraries list because that's where proposals >> >> generally go, although this isn't strictly a library issue. If it >> >>should be >> >> on a different list I'll move it. >> >> >> >> >> >> >> >> -- >> >> View this message in context: >> >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na >> >> >>bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm >> >> >>l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH >> >> >>H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W >> >>70W4uY&e= >> >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> >> >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi- >> >> >>2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD >> >> >>0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t >> >>vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= >> >_______________________________________________ >> >Libraries mailing list >> >Libraries at haskell.org >> > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2 >> >> >Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T >> >> >3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW >> >aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Nov 4 19:32:56 2015 From: david.feuer at gmail.com (David Feuer) Date: Wed, 4 Nov 2015 14:32:56 -0500 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: -1. This is a bad solution to a non-existent problem. On Nov 4, 2015 2:31 PM, "Edward Kmett" wrote: > This has been proposed before and rejected before on many separate > occasions. > > (.) already has a complicated enough role in our lives being used for > qualified names as well as composition. > > Just.Just already doesn't parse as you'd expect due to its double-life. > Giving it a third job breaks every f.g out there in user code and actively > worsens systems that already exist for this purpose that compose better. > > I remain strongly in the -1 camp. > > -Edward > > > > On Wed, Nov 4, 2015 at 1:57 PM, Andrew Gibiansky < > andrew.gibiansky at gmail.com> wrote: > >> I'm not on either side of this fence yet, but keep in mind that this >> can't just be done with an operator, because, if I understand the proposal >> correctly, the proposed dot hack would have a precedence *higher* than >> function application. >> >> That is, code like >> >> print person.name >> >> would desugar to >> >> print (name person) >> >> and not to >> >> name (print person) >> >> This is something that can't be replicated with current Haskell and is >> the crux of the issue, I think. >> >> As Chris Done said, "All of this because Haskellers are allergic to >> parentheses." (A true comment, if perhaps one I maybe don't agree with) >> >> -- Andrew >> >> On Wed, Nov 4, 2015 at 10:28 AM, Andrew Farmer wrote: >> >>> I'm a strong -1. This already exists as an operator anyway: >>> >>> >>> http://hackage.haskell.org/package/lens-4.13/docs/Control-Lens-Operators.ht >>> ml#v:-38- >>> >>> >>> >>> On 11/4/15, 6:16 AM, "Libraries on behalf of Dominique Devriese" >>> >> dominique.devriese at cs.kuleuven.be> wrote: >>> >>> >+1 >>> > >>> >I'm convinced that this proposed extension would be extremely natural >>> >and practical if we give it a chance. The fact that it may conflict >>> >with previous, less natural syntax choices (lens composition with . >>> >comes to mind) should not be counted against an opt-in extension. >>> >Lens packages could easily provide an alternative notation for their . >>> >for when the extension is enabled. >>> > >>> >Regards, >>> >Dominique >>> > >>> >2015-11-04 11:44 GMT+01:00 Jeremy : >>> >> Dot as Postfix Function Apply >>> >> >>> >>( >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__ghc.haskell.org_tra >>> >>> >>c_ghc_wiki_Records_DeclaredOverloadedRecordFields_DotPostfix&d=CwICAg&c=5 >>> >>> >>VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnG >>> >>xAokec8hTZyMcwu8voE&s=ZxiyXvL6jUpla8Ikbdndqpoft7zJnvOGqHgicaQBP2I&e= ) >>> >> was originally part of ORF, but dropped to keep the scope/discussion >>> >>more >>> >> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose >>> >>dot >>> >> postfix syntax. >>> >> >>> >> The idea is that instead of >>> >> >>> >> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName >>> person) >>> >> >>> >> we could have >>> >> >>> >> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName >>> >> >>> >> This is a simple source-to-source translation with no changes to the >>> >>type >>> >> system (TDNR is an orthogonal proposal). The advantages are: >>> >> >>> >> 1. Code that's easier to read/write. >>> >> 2. Familiar to users of almost every other programming language. >>> >> 3. IDE auto-complete - an IDE can suggest functions applicable to >>> the >>> >> variable after typing . >>> >> >>> >> This would be an opt-in extension. >>> >> >>> >> I'm posting this to the libraries list because that's where proposals >>> >> generally go, although this isn't strictly a library issue. If it >>> >>should be >>> >> on a different list I'll move it. >>> >> >>> >> >>> >> >>> >> -- >>> >> View this message in context: >>> >> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__haskell.1045720.n5.na >>> >>> >>bble.com_Proposal-2DDot-2Das-2DPostfix-2DFunction-2DApply-2Dtp5821620.htm >>> >>> >>l&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T3rI1L_0LSiPtRSfw&m=YDwguWCVjH >>> >>> >>H3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=L_6yc68pNbnhlMLCkcHBSU8qXF8vWd69dLL7W >>> >>70W4uY&e= >>> >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >>> >> _______________________________________________ >>> >> Libraries mailing list >>> >> Libraries at haskell.org >>> >> >>> >> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi- >>> >>> >>2Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD >>> >>> >>0T3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8t >>> >>vSWaEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= >>> >_______________________________________________ >>> >Libraries mailing list >>> >Libraries at haskell.org >>> > >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.haskell.org_cgi-2 >>> >>> >Dbin_mailman_listinfo_libraries&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=jwmD0T >>> >>> >3rI1L_0LSiPtRSfw&m=YDwguWCVjHH3yABXsya8ZZnGxAokec8hTZyMcwu8voE&s=qUbr8tvSW >>> >aEIz_6yV9i3K8w1K81GGvLlkTX85egYfH4&e= >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanablack at amok.cc Wed Nov 4 19:36:04 2015 From: lanablack at amok.cc (Lana Black) Date: Wed, 4 Nov 2015 19:36:04 +0000 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <20151104193603.GA21373@glow> On 03:44 Wed 04 Nov , Jeremy wrote: > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. > > The idea is that instead of > > (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) > > we could have > > person.title ++ " " ++ person.firstName ++ " " ++ person.lastName > > This is a simple source-to-source translation with no changes to the type > system (TDNR is an orthogonal proposal). The advantages are: > > 1. Code that's easier to read/write. > 2. Familiar to users of almost every other programming language. > 3. IDE auto-complete - an IDE can suggest functions applicable to the > variable after typing . > > This would be an opt-in extension. > > I'm posting this to the libraries list because that's where proposals > generally go, although this isn't strictly a library issue. If it should be > on a different list I'll move it. > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -1. There already is (&) in Data.Function. A better idea would be to re-export it from Prelude. From voldermort at hotmail.com Wed Nov 4 19:40:04 2015 From: voldermort at hotmail.com (Harry .) Date: Wed, 4 Nov 2015 19:40:04 +0000 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com>, Message-ID: When you consider that every other programming language in common use (and almost every language not in common use as well) allows you to write: print person.name while Haskell requires something like: print (person & name) or print $ person.^name and even that after importing a third-party library or defining it yourself, you begin to understand why beginners think that Haskell looks more like Japanese emoticons than programming. From voldermort at hotmail.com Wed Nov 4 19:42:53 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 4 Nov 2015 12:42:53 -0700 (MST) Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <1446666173869-5821672.post@n5.nabble.com> Edward Kmett-2 wrote > Just.Just already doesn't parse as you'd expect due to its double-life. > Giving it a third job breaks every f.g out there in user code and actively > worsens systems that already exist for this purpose that compose better. The proposal actually removes .'s ambiguity by defining syntactically whether it's an operator (surrounded by spaces) or namespace/postfix (without spaces). It will only break existing code if you turn on the extension for it. -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620p5821672.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From david.feuer at gmail.com Wed Nov 4 19:44:08 2015 From: david.feuer at gmail.com (David Feuer) Date: Wed, 4 Nov 2015 14:44:08 -0500 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: print (name person) person.^name & print Sorry, I'm not seeing the disaster yet. On Nov 4, 2015 2:40 PM, "Harry ." wrote: > When you consider that every other programming language in common use (and > almost every language not in common use as well) allows you to write: > > print person.name > > while Haskell requires something like: > > print (person & name) or > > print $ person.^name > > and even that after importing a third-party library or defining it > yourself, you begin to understand why beginners think that Haskell looks > more like Japanese emoticons than programming. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Nov 4 19:45:14 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 4 Nov 2015 20:45:14 +0100 (CET) Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: Message-ID: On Tue, 20 Oct 2015, Johan Tibell wrote: > I'm taking a step back from day-to-day library work. We have seen a lot of frustration with recent breaking changes to Prelude. This makes me wonder whether we should try a different way of performing votings. Although there seems to be some agreement that majority votes are not the ultimate tool to make decisions, controversal proposals such as the FTP were essentially made by majority votes (strictly speaking it was a majority that convinced the benevolent dictators). I have read about different voting systems that do not try to maximize the number of happy people but try to minimize the number of frustrated people. Applied to libraries at haskell.org we would no longer count +1, -1 and 0, but only -1 and 0 anymore, but we would also consider the status quo as one of the alternatives. E.g. if someone proposes something like FTP you would not answer +1 but instead: proposal: 0 status quo: -1 or proposal: 0 status quo: 0 I guess that this way we may find out that some proposals are nice to have for a majority of people but the status quo is not bad, too, and in summary there is no pressure to frustrate a (still big) minority. How about that? Maybe other people have more experience with that voting system or have suggestions for alternatives. (I am curious, whether someone replies "+1" to this suggestion. :-) From lemming at henning-thielemann.de Wed Nov 4 20:08:49 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 4 Nov 2015 21:08:49 +0100 (CET) Subject: warnings per organisation (Was: 3 release policy) In-Reply-To: References: <1445370906741-5820363.post@n5.nabble.com> Message-ID: On Wed, 21 Oct 2015, Simon Peyton Jones wrote: > Trouble is, any particular categorisation will be slightly wrong for > almost everyone. Would it help if any one organisation could list the > warnings that it wanted to hear about (and then eliminate), put that in > a .ghc file, OPTIONS pragma, or on the command line? So, in effect, > have a per-org warning categorisation. (It would make for a very long > command line.) I think it must be specified in the Cabal file of a project, such that other programmers get the same list of warnings as the main developer. And that's actually how it currently works: If I want to see warnings I must add GHC-Options: -Wall to a Cabal file, and sometimes I add more warning switches if I recall them. From ekmett at gmail.com Wed Nov 4 20:20:00 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 4 Nov 2015 15:20:00 -0500 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: Precedence and syntax in a language tells you a lot about what the language considers important. We take the 'quietest' syntax for things that we want to have fade into the background. Whitespace and periods are both very quiet syntax. In math ' ' is often multiplication, in the lambda calculus it is function application. We choose ' ' to have the tightest precedence in Haskell in a way that nicely emphasizes the importance of functions here. Admittedly we already have two awkward exceptions there that routinely throw folks for loops. @ syntax in patterns and the {}'s used by record syntax both bind tighter than whitespace application. We choose . for function composition a.) because it on the keyboard and again, it emphasizes the importance of functions. Functions compose and you can make more interesting things out of the parts, the field accessor syntax you propose here does not compose particularly well. With other solutions available today that this proposal actively makes worse, I can both read and write back to those fields You're asking for (.), one of the most common symbols in Haskell code today to take on another meaning, furthering confusion for its current standard role, for it to effectively alternate binding looser than ' ' when you put spaces around it to tighter than ' ' when you don't while simultaneously changing semantics entirely. Is it confusing to newcomers that (.) doesn't bind tighter than ' ' in haskell? Sure. But causing that to randomly change back and forth is more confusing still. -Edward On Wed, Nov 4, 2015 at 2:40 PM, Harry . wrote: > When you consider that every other programming language in common use (and > almost every language not in common use as well) allows you to write: > > print person.name > > while Haskell requires something like: > > print (person & name) or > > print $ person.^name > > and even that after importing a third-party library or defining it > yourself, you begin to understand why beginners think that Haskell looks > more like Japanese emoticons than programming. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Wed Nov 4 20:37:41 2015 From: johnw at newartisans.com (John Wiegley) Date: Wed, 04 Nov 2015 15:37:41 -0500 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: (Henning Thielemann's message of "Wed, 4 Nov 2015 20:45:14 +0100 (CET)") References: Message-ID: >>>>> Henning Thielemann writes: > Applied to libraries at haskell.org we would no longer count +1, -1 and 0, but > only -1 and 0 anymore, but we would also consider the status quo as one of > the alternatives. The only problem with not hearing positive votes is that we don't know the size of the number of people in favor. Here's what ANSI/ISO does in the case of C++: We have a tiered voting system. First, you take a "straw poll" (say, on this list) to determine the level of interest. To this, people vote: SA WA DC WF SF. That is: Strongly Against, Weakly Against, Don't Care, Weakly in Favor, Strongly in Favor. Only motions largely in favor move forward. Those that have Strongly Against votes lead to further discussion with those who are disappointed. We try not to force anything down anyone's throats if it can be avoided. SA votes really mean something, perhaps even more than SF. If a motion is largely in favor, it moves to formal proposal before the committee (which in this case might be the Haskell Prime committee?). Each member of that committee has a vote, and simple majority decides whether it moves to the last round. In the last round, delegates from each country who make the final decision by majority. In the case of Haskell, our "countries" might be different: Academia, Industry, Hobbyists, etc. These delegates are supposed to represent the will of their constituents, but can vote however they wish. In this way, no vote is a surprise, and there are several stages of both public and expert consideration as it moves toward a formal conclusion. John From danburton.email at gmail.com Wed Nov 4 20:41:25 2015 From: danburton.email at gmail.com (Dan Burton) Date: Wed, 4 Nov 2015 12:41:25 -0800 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: +1, it's no worse than module syntax, and it's opt-in. I suppose my vote bumps it up from -1000 to -999. /shrug Dot as postfix function application is frankly a great idea that exists in many many languages. It's great for intellisense and it's often great for reading code left to right. It may not be the best fit for Haskell, but Haskell has never been one of those "one right way to code" sort of languages. On Wednesday, November 4, 2015, Jeremy wrote: > Dot as Postfix Function Apply > ( > https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix > ) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. > > The idea is that instead of > > (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) > > we could have > > person.title ++ " " ++ person.firstName ++ " " ++ person.lastName > > This is a simple source-to-source translation with no changes to the type > system (TDNR is an orthogonal proposal). The advantages are: > > 1. Code that's easier to read/write. > 2. Familiar to users of almost every other programming language. > 3. IDE auto-complete - an IDE can suggest functions applicable to the > variable after typing . > > This would be an opt-in extension. > > I'm posting this to the libraries list because that's where proposals > generally go, although this isn't strictly a library issue. If it should be > on a different list I'll move it. > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Wed Nov 4 20:44:46 2015 From: danburton.email at gmail.com (Dan Burton) Date: Wed, 4 Nov 2015 12:44:46 -0800 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: > > Is it confusing to newcomers that (.) doesn't bind tighter than ' ' in > haskell? Sure. But causing that to randomly change back and forth is more > confusing still. It already does randomly change back and forth though, due to module syntax. With the proposed option turned on, the change seems *less* random to me, being solely based on whitespace and not *also* based on whether the LHS is a module name. -- Dan Burton On Wed, Nov 4, 2015 at 12:20 PM, Edward Kmett wrote: > Precedence and syntax in a language tells you a lot about what the > language considers important. We take the 'quietest' syntax for things that > we want to have fade into the background. Whitespace and periods are both > very quiet syntax. > > In math ' ' is often multiplication, in the lambda calculus it is function > application. > > We choose ' ' to have the tightest precedence in Haskell in a way that > nicely emphasizes the importance of functions here. Admittedly we already > have two awkward exceptions there that routinely throw folks for loops. @ > syntax in patterns and the {}'s used by record syntax both bind tighter > than whitespace application. > > We choose . for function composition a.) because it on the keyboard and > again, it emphasizes the importance of functions. Functions compose and you > can make more interesting things out of the parts, the field accessor > syntax you propose here does not compose particularly well. > > With other solutions available today that this proposal actively makes > worse, I can both read and write back to those fields > > You're asking for (.), one of the most common symbols in Haskell code > today to take on another meaning, furthering confusion for its current > standard role, for it to effectively alternate binding looser than ' ' when > you put spaces around it to tighter than ' ' when you don't while > simultaneously changing semantics entirely. > > Is it confusing to newcomers that (.) doesn't bind tighter than ' ' in > haskell? Sure. But causing that to randomly change back and forth is more > confusing still. > > -Edward > > On Wed, Nov 4, 2015 at 2:40 PM, Harry . wrote: > >> When you consider that every other programming language in common use >> (and almost every language not in common use as well) allows you to write: >> >> print person.name >> >> while Haskell requires something like: >> >> print (person & name) or >> >> print $ person.^name >> >> and even that after importing a third-party library or defining it >> yourself, you begin to understand why beginners think that Haskell looks >> more like Japanese emoticons than programming. >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Nov 4 21:09:05 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 04 Nov 2015 21:09:05 +0000 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: On Wed, Nov 4, 2015 at 2:41 PM Dan Burton wrote: > +1, it's no worse than module syntax, and it's opt-in. > > I suppose my vote bumps it up from -1000 to -999. /shrug > > Dot as postfix function application is frankly a great idea that exists in > many many languages. It's great for intellisense and it's often great for > reading code left to right. It may not be the best fit for Haskell, but > Haskell has never been one of those "one right way to code" sort of > languages. > This isn't about dot as postfix function application. You can already do that: import Prelude hiding ((.)) a . f = f a main = 23 . print This is about changing the syntax of the language to make it more comfortable to people coming from OO languages, in particular mimicking the way most of those languages select features from an object. The syntax change is making dot without spaces bind tighter than function application so you can say "print object.element" instead of having to say print (element object)" or "print $ element object". Alexander Berntsen suggested adding a new fixity so you could declare operators that bind tighter than function application. That would let you write "print object . element" by declaring the fixity of "." to be that new fixity. Since such a change doesn't break any existing code, it doesn't need to be an extension that's enabled. It's a need I've felt every so often myself. -1. Once you get past wanting to write OO code in Haskell, this itch should go away. I think it would be like all the "OO in haskell" libraries that newcomers write, then quit using once they get past that desire. At the very least, make this a general change, so that namename without spaces binds tighter than functions, so it's useful for more than writing code that looks like Pyhton/C/C++/etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhoermann at gmail.com Wed Nov 4 21:20:49 2015 From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=) Date: Wed, 4 Nov 2015 22:20:49 +0100 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: Message-ID: On Wed, Nov 4, 2015 at 9:37 PM, John Wiegley wrote: > In the last round, delegates from each country who make the final decision by > majority. In the case of Haskell, our "countries" might be different: > Academia, Industry, Hobbyists, etc. These delegates are supposed to represent > the will of their constituents, but can vote however they wish. The trouble with this would be that the split in the community does not seem to be between e.g. the interests of academia and industry but between conversative people in academia and the industry and those who are more open to language changes in both groups. I suspect the divide isn't even close to the same on most questions either so a representative system might be tricky to implement. Maybe if some form of grouping of people in the community is necessary it should be made along the lines of the groups we saw mentioned in recent FTP discussions: authors of printed books, new Haskell users coming from other languages and new Haskell users learning it without prior experience, Haskell teachers, maintainers of libraries spanning many GHC versions, users writing new code without backwards compatibility concerns, those interested in using only one of the existing Haskell standards without language extensions and those interested in using the latest extensions available,... Perhaps in future discussions a focus should be on identifying and grouping the users affected by each change and each user should be encouraged to vote +1, 0 or -1 for each of the groups they are a part of separately, explaining how they arrived at their final vote themselves. Matthias H?rmann From mail at joachim-breitner.de Wed Nov 4 23:26:00 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 05 Nov 2015 00:26:00 +0100 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: Message-ID: <1446679560.1455.10.camel@joachim-breitner.de> Hi, I?m not sure if the problem is within the voting system. At least for me, the problem is mostly that I simply can?t assess the consequences of a change. Often, I am easily convinced that the change would be for the better, but I can?t precisely prognose how much impact it would have on me with my work with Haskell, let alone on others. Even more so, I have a hard time to assess the cost of a change: Will it cause major annoyance for many people? Will it just be something that a few people will have to take care of once and it?s done? Will it be smooth or is there a high risk of unexpected knock-on effects? In the end, I tend to be skeptical of most changes, but convincable by a carefully laid out transition plan, hoping that he who created the plan thought it trough. Ideally, the benefits and costs of a change could be quantified objectively, and we would not have to vote in the first place. But that?s of course not possible. (This mail does not offer solutions, or even ask for any, sorry. It was just a slight sigh, maybe with the hope to get people to too excited about change the either way, because it seems we cannot avoid suboptimal choices anyways.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From greg at gregweber.info Thu Nov 5 00:19:51 2015 From: greg at gregweber.info (Greg Weber) Date: Wed, 4 Nov 2015 16:19:51 -0800 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: +1 for an opt-in extension. I am not sure if any approval is needed from the libraries committee for an optional extension like this if you are willing to do the work to bring it to fruition yourself. On Wed, Nov 4, 2015 at 2:44 AM, Jeremy wrote: > Dot as Postfix Function Apply > ( > https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix > ) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. > > The idea is that instead of > > (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) > > we could have > > person.title ++ " " ++ person.firstName ++ " " ++ person.lastName > > This is a simple source-to-source translation with no changes to the type > system (TDNR is an orthogonal proposal). The advantages are: > > 1. Code that's easier to read/write. > 2. Familiar to users of almost every other programming language. > 3. IDE auto-complete - an IDE can suggest functions applicable to the > variable after typing . > > This would be an opt-in extension. > > I'm posting this to the libraries list because that's where proposals > generally go, although this isn't strictly a library issue. If it should be > on a different list I'll move it. > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Thu Nov 5 01:23:40 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Wed, 4 Nov 2015 17:23:40 -0800 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: Perhaps someone could test it out by implementing it as part of ghc-reskin ? Personally, I do feel like we need a better way to evolve the *syntax* of the language. The syntax is a minor concern, so almost all syntactic proposals get voted strongly down for all the reasons brought up above. However, syntax when taken all together is certainly not minor. On Wed, Nov 4, 2015 at 4:19 PM, Greg Weber wrote: > +1 for an opt-in extension. I am not sure if any approval is needed from > the libraries committee for an optional extension like this if you are > willing to do the work to bring it to fruition yourself. > > On Wed, Nov 4, 2015 at 2:44 AM, Jeremy wrote: > >> Dot as Postfix Function Apply >> ( >> https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix >> ) >> was originally part of ORF, but dropped to keep the scope/discussion more >> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot >> postfix syntax. >> >> The idea is that instead of >> >> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) >> >> we could have >> >> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName >> >> This is a simple source-to-source translation with no changes to the type >> system (TDNR is an orthogonal proposal). The advantages are: >> >> 1. Code that's easier to read/write. >> 2. Familiar to users of almost every other programming language. >> 3. IDE auto-complete - an IDE can suggest functions applicable to the >> variable after typing . >> >> This would be an opt-in extension. >> >> I'm posting this to the libraries list because that's where proposals >> generally go, although this isn't strictly a library issue. If it should >> be >> on a different list I'll move it. >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Nov 5 01:24:38 2015 From: david.feuer at gmail.com (David Feuer) Date: Wed, 4 Nov 2015 20:24:38 -0500 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: The library committee does not generally have any formal authority over or involvement in language extensions or language changes. I would argue this entire discussion should probably have taken place elsewhere (e.g., haskell-cafe or ghc-devs). That said, the library gurus likely do have some sense of how much you're likely to gain by adding such an extension. While I'm writing this message, I think I might as well try to explain a bit better why I think the proposed extension is a bad idea. In a procedural language, the field dot is an all-purpose way to narrow focus from a record or object to a field or method. In C, the following all make sense (I think--my C is rusty). foo = fish.dog (fish.cat) + 4 fish.cat = 12 fish.cat += 17 shark = &fish.cat In Haskell, only the first usage is sensible. Once the hypothetical .cat is applied, the fish is out of the picture. Lenses, on the other hand, offer sensible ways to talk about functional approximations of all of these things. I believe a syntactic extension making lenses easier to use could be a big win, but the current proposal just makes easy things easy, which they already are. Others have, correctly, mentioned the use of . in the module system as justification. This is sensible, since modules look a bit like records if you squint enough. But I think most Haskellers will agree that they'd rather see modules look more like records than the other way around. On Nov 4, 2015 7:20 PM, "Greg Weber" wrote: > +1 for an opt-in extension. I am not sure if any approval is needed from > the libraries committee for an optional extension like this if you are > willing to do the work to bring it to fruition yourself. > > On Wed, Nov 4, 2015 at 2:44 AM, Jeremy wrote: > >> Dot as Postfix Function Apply >> ( >> https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix >> ) >> was originally part of ORF, but dropped to keep the scope/discussion more >> manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot >> postfix syntax. >> >> The idea is that instead of >> >> (title person) ++ " " ++ (firstName person) ++ " " ++ (lastName person) >> >> we could have >> >> person.title ++ " " ++ person.firstName ++ " " ++ person.lastName >> >> This is a simple source-to-source translation with no changes to the type >> system (TDNR is an orthogonal proposal). The advantages are: >> >> 1. Code that's easier to read/write. >> 2. Familiar to users of almost every other programming language. >> 3. IDE auto-complete - an IDE can suggest functions applicable to the >> variable after typing . >> >> This would be an opt-in extension. >> >> I'm posting this to the libraries list because that's where proposals >> generally go, although this isn't strictly a library issue. If it should >> be >> on a different list I'll move it. >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Proposal-Dot-as-Postfix-Function-Apply-tp5821620.html >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Nov 5 06:22:19 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 5 Nov 2015 07:22:19 +0100 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <563AF59B.3000409@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/11/15 22:09, Mike Meyer wrote: > Alexander Berntsen suggested adding a new fixity so you could > declare operators that bind tighter than function application. > > [...] > > Since such a change doesn't break any existing code, it doesn't > need to be an extension that's enabled. It's a need I've felt every > so often myself. This is false. If it weren't an extension, GHC would accept (more) programs that are not valid Haskell 2010. This would be a mistake. Even if it doesn't break any existing code, it *would extend* the language. As such, it should, naturally, be a language extension. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWOvWaAAoJENQqWdRUGk8B3pIQALfE214fi0OmtukqURYKg52n 4TAu99yDVIZzZmoYe4ZMGHqJoi1eG4DnYw/pNgn+Q4CLRea44i2/rOJkmlWu141m SV/Kuhiji4ciQg6XtX7c60s441OdQrvq7ZEzSyM0TpxGFVFJ08E8uTySTnV/RTcX fc8+F04GuA3NIESazIHz3QaYNjzBgtLHe8YZCQkUG/x8FNnvaPV5Dbh60B/2g6Yk BavmTHWZccVs/fXplLNLms+t5iWaJQKJTpUi5cnXCLKjVnW4njpsSMQRt5IN+wRD r1qzcpfwPtRDr2Pd4co37KyszKPyWeKNU+vO7KlOmNArfrR9wSKtwip5hx9+KJMH OG5hq8aDNy1sas0zN2DKhhynaFxP90OULaDq/xN2IBFOje4+VyHmGP0dZHev+3NT ggjhf6hOG8ALTzzSuBUJRAiF7s0g73NVeqSCo/p/0g2Aw8cXzdme45XIDuxLvsaf MAFYEf+rR2gT5k2WylU95wlu4lytuE3IGYn1euLalkJZJrLknMySn8RqqQTQGB5P IHZwHb17luGaPQWjb6Bd03fYF7ygoaq0SRRaD1KigA9XYReC7Duq/rz/g561vykG 0y0RygwL0VjfNbQw/b/BsCYpfsOobBZrLzSqp72SWHBn4CkCoMpLRPPV7H2OLdjL tbmy4JyULPSXEK68+C78 =u6Ue -----END PGP SIGNATURE----- From jules at jellybean.co.uk Thu Nov 5 08:21:14 2015 From: jules at jellybean.co.uk (Jules Bean) Date: Thu, 5 Nov 2015 08:21:14 +0000 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <0971D72A-D623-4BFD-A0D4-35366B45A094@jellybean.co.uk> -1 from me. In particular reference to the comment below: On 4 Nov 2015, at 14:16, Dominique Devriese wrote: > The fact that it may conflict > with previous, less natural syntax choices (lens composition with . > comes to mind) should not be counted against an opt-in extension. Lens composition with (.) is not really a syntax choice - Lens composition with (.) is simply function composition with (.) which is a fairly deeply-set Haskell choice. I can see arguments against using (.) for function composition but I don?t think anyone would seriously consider changing that now: and Lens composition will always have the same syntax as function composition. It just so happens that Lens composition with (.) gives us the ability to write person^.job.title which is one of those nice coincidences which looks a bit like C-style object dereference. Jules From adam at well-typed.com Thu Nov 5 09:03:00 2015 From: adam at well-typed.com (Adam Gundry) Date: Thu, 5 Nov 2015 09:03:00 +0000 Subject: Status of OverloadedRecordFields [Was: Re: Proposal: Dot as Postfix Function Apply] In-Reply-To: <1446633873720-5821620.post@n5.nabble.com> References: <1446633873720-5821620.post@n5.nabble.com> Message-ID: <563B1B44.3010302@well-typed.com> [copying ghc-devs as the following is perhaps more relevant there] On 04/11/15 10:44, Jeremy wrote: > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. I'm going to stay out of the discussion over the proposed syntax extension, but I feel like I should do some expectation management about ORF in GHC 8.0. As the wiki page [1] makes clear, ORF has been divided into three components, and so far only one of these is in GHC HEAD. The first part is a language extension, DuplicateRecordFields, which allows field names to be duplicated provided they are unambiguous. (It does not allow any kind of polymorphism over record fields.) This is already in HEAD. The second part is another language extension, OverloadedLabels, which introduces a new syntax #x for an identifier whose type is inferred and may depend on the text of the identifier. This is implemented and up on Phabricator [2], but not yet in HEAD. It should make GHC 8.0, but I'm wary about giving cast-iron guarantees. The third part, which is necessary for the OverloadedLabels syntax to be used for polymorphism over record fields, involves typeclass constraints that capture when a type has a particular field, with the instances provided automatically by GHC. This is not yet implemented in the intended form, and is unlikely to make GHC 8.0 (barring me having a sudden outbreak of free time...). Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [2] https://phabricator.haskell.org/D1331 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From hvr at gnu.org Thu Nov 5 10:46:32 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 05 Nov 2015 11:46:32 +0100 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87io6zmr2x.fsf@gnu.org> (Herbert Valerio Riedel's message of "Thu, 24 Sep 2015 23:43:02 +0200") References: <87io6zmr2x.fsf@gnu.org> Message-ID: <87611gpvuf.fsf@gnu.org> Hello everybody, Based on the feedback gathered from the discussion, the proposal has been revised to address the raised concerns. The highlights are: - A new stretched out transition scheme complying with the recently enacted ?3-release policy (and beyond) has been devised. - Unifying `>>`/`*>` has been incorporated into the proposal in the interest of bundling changes of obviously related changes. - Moreover, the feasibility of automatic refactoring tooling was investigated and resulted in the working `Hs2010To201x` proof-of-concept. Please re-read the revised proposal at https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn for more details (or use the Wiki's diffing feature to see what changed relative to the original revision) if you want to comment, so we can focus on discussing the actual revised version. Also, as per proposal guidelines, and more importantly, for the benefit of those that lost track of this rather complex discussion, I've tried to summarize the core of discussion over at https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion More importantly, based on feedback gathered as well as concerns raised throughout the discussion, I've revised and extended the proposal into a "2nd edition MRP". I feel confident the new revised proposal addresses the major concerns as well as adhering to the recently requested 3-yr compatibility policy. PS: One common oversight I noticed when reviewing the discussion is that the last-minute proposal addition -- of unifying `>>`/`*>` in the same vein as `pure`/`return` -- wasn't noticed by many who joined the debate late. However, Unifying `>>`/`*>` and `pure`/`return` are in my opinion strongly related concerns as they share the same rationale about correctness issues and it doesn't make sense to do one without the other. However, the transition time-scales could be set slightly different to account for the more breaking nature of effectively changing `>>`'s current default method operational semantics. Thanks, Herbert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From fa-ml at ariis.it Thu Nov 5 14:18:39 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 5 Nov 2015 15:18:39 +0100 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87611gpvuf.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: <20151105141839.GB1847@casa.casa> On Thu, Nov 05, 2015 at 11:46:32AM +0100, Herbert Valerio Riedel wrote: > Hello everybody, Hello, I would suggest to start a new thread for this proposal. The old one (check it on gmane [1]) is approaching "unholy evil" levels of length/nested discussion, a fresh start might benefit the discussion (and result in cleaner archiving). [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/25380/focus=118576 From greg at gregweber.info Thu Nov 5 14:53:39 2015 From: greg at gregweber.info (Greg Weber) Date: Thu, 5 Nov 2015 06:53:39 -0800 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <20151105141839.GB1847@casa.casa> References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> <20151105141839.GB1847@casa.casa> Message-ID: Thanks for the clear revisions! It is unclear from the proposal how well the automatic re-factoring tool is expected to work. On Thu, Nov 5, 2015 at 6:18 AM, Francesco Ariis wrote: > On Thu, Nov 05, 2015 at 11:46:32AM +0100, Herbert Valerio Riedel wrote: > > Hello everybody, > > Hello, > I would suggest to start a new thread for this proposal. > The old one (check it on gmane [1]) is approaching "unholy evil" > levels of length/nested discussion, a fresh start might benefit > the discussion (and result in cleaner archiving). > > [1] > http://thread.gmane.org/gmane.comp.lang.haskell.libraries/25380/focus=118576 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Nov 5 15:00:50 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 5 Nov 2015 16:00:50 +0100 Subject: MRP Summary & revised MRP 2ed In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> <20151105141839.GB1847@casa.casa> Message-ID: <563B6F22.7080708@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/11/15 15:53, Greg Weber wrote: > Thanks for the clear revisions! It is unclear from the proposal > how well the automatic re-factoring tool is expected to work. The obvious answer is that it will be as good as possible. :-] It would be very beneficial if people who use Haskell in an academic or commercial setting -- thus actively benefiting from it -- were able to spend some of their time on this project. That way the roof for "as good as possible" will likely be raised considerably. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWO28fAAoJENQqWdRUGk8Bfm4QAMpMJakhtwopvvJDobr4svZ2 WE4oW88d6LoDIzFTG5654RG78fyKkyGE+WllfH+X1OgV/3/YT1iczE73ysgxS5k4 wivhEzt4HvlITmF8H6qYJDie+X08IHgaCUMseMOhh/fxyy+YF1cr4hF5P9mEWP+9 ti4HC3Y4rjB86U78mbhTVUj6fiF2NLkM7Y2Bxf2vHvbfGwUVh4QA8sSyM7rSSjDP OlZW3fMMNFuhaqvIlYOcr/slHq/r+pe+88X5MJLPen1ALPksjzdyd1Izw1wdCL3y zTGMO94aFlvkbomGCgCUzCFaPUqewvn0P0W5I38jmLM8D7AwRTQBTd/oz53AumsK Km0RtHEs7MW5FQ8dA5+vMLZblxjpXAK9BOvUIkr1Rt44wnDLU86hWEBBFsb5H0+m Kdc5WGfn4AjuESXvG29UrLSyU2eAwYUF60W8Y2hEt9nGs/IrrtSjpC46W5FPi9LR F1GHuYBJobEQ6K6TvjVzQ73ajPH9Vwm3d8+BV8eBd5Z62MkgF23M0HWHuR0JUo4X YjLutYzo+oAkeF4tOzLO0TIvQx6pyncj/CDMZL+ZLMrhHYP2yIuXEQixXs3yi2og GJi453l0RbCEjKj+cPek/ZCwtNtf/tMvSD/Rr6yjCAIE67eaC9h/NsxFn9fNQzRJ O3cfg4wlIvcZDSsx6qGw =jB4v -----END PGP SIGNATURE----- From hvriedel at gmail.com Thu Nov 5 22:31:12 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 05 Nov 2015 23:31:12 +0100 Subject: MRP Summary & revised MRP 2ed In-Reply-To: (Greg Weber's message of "Thu, 5 Nov 2015 06:53:39 -0800") References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> <20151105141839.GB1847@casa.casa> Message-ID: <87twp0m633.fsf@gmail.com> Hi, On 2015-11-05 at 15:53:39 +0100, Greg Weber wrote: > Thanks for the clear revisions! It is unclear from the proposal how well > the automatic re-factoring tool is expected to work. Currently, Hs2010To201x does the following few things: When a `Monad` instance definition is detected in a module, - if needed, define respective `Functor` instance (AMP) - if needed, define respective `Applicative` instance (AMP) - if needed, refactor return/pure definitions into canonical form (MRP) This works fairly well for most common `Monad` instances. I ran it on Cabal's code-base (for which only the MRP refactoring was relevant), and the result looked very promising: https://gist.github.com/hvr/cd35fbcff9be6f3cb2a9 However, the major obstacle so far is CPP, which generally causes problems with other tooling as well, and in particular /can/ confuse ghc-exactprint. Another source of problems are orphan-instances (specifically when the `Applicative` instance is defined in a different module from the module where the `Monad` instance is defined) as the tool currently operates on single modules at a time. Finally, the less frequent cases of nested Monads which require to construct proper instance constraints for `Functor`/`Applicatives` instances are not handled adequately yet. Examples are `instance (Monad m) => Monad (ListT m)` or `instance (Monad m) => Monad (StateT s m)`. --HVR From dominique.devriese at cs.kuleuven.be Fri Nov 6 08:31:28 2015 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Fri, 6 Nov 2015 09:31:28 +0100 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: <0971D72A-D623-4BFD-A0D4-35366B45A094@jellybean.co.uk> References: <1446633873720-5821620.post@n5.nabble.com> <0971D72A-D623-4BFD-A0D4-35366B45A094@jellybean.co.uk> Message-ID: 2015-11-05 9:21 GMT+01:00 Jules Bean : >> The fact that it may conflict >> with previous, less natural syntax choices (lens composition with . >> comes to mind) should not be counted against an opt-in extension. > > Lens composition with (.) is not really a syntax choice - Lens composition with (.) is simply function composition with (.) which is a fairly deeply-set Haskell choice. I can see arguments against using (.) for function composition but I don?t think anyone would seriously consider changing that now: and Lens composition will always have the same syntax as function composition. > > It just so happens that Lens composition with (.) gives us the ability to write person^.job.title which is one of those nice coincidences which looks a bit like C-style object dereference. This coincidence is nice because it approximates expectations from other languages. Unfortunately, this approximation breaks down quickly in only slightly more complex cases like `func person^.job.title`, "person^.someFuncProperty someArgument" and doesn't extend to writing `person.job.title`, leading (imho) to confusion and an unnatural feel. Also, I'm not sure why there's a "vote" about this now. As someone already mentioned, no community approval is needed to *first* implement it in some way (perhaps using ghc-reskin as suggested by someone), experiment with it and see if it makes as much sense as some of us expect. Regards, Dominique From jules at jellybean.co.uk Fri Nov 6 08:53:30 2015 From: jules at jellybean.co.uk (Jules Bean) Date: Fri, 6 Nov 2015 08:53:30 +0000 Subject: Proposal: Dot as Postfix Function Apply In-Reply-To: References: <1446633873720-5821620.post@n5.nabble.com> <0971D72A-D623-4BFD-A0D4-35366B45A094@jellybean.co.uk> Message-ID: On 6 Nov 2015, at 08:31, Dominique Devriese wrote: > 2015-11-05 9:21 GMT+01:00 Jules Bean : >>> The fact that it may conflict >>> with previous, less natural syntax choices (lens composition with . >>> comes to mind) should not be counted against an opt-in extension. >> >> Lens composition with (.) is not really a syntax choice - Lens composition with (.) is simply function composition with (.) which is a fairly deeply-set Haskell choice. I can see arguments against using (.) for function composition but I don?t think anyone would seriously consider changing that now: and Lens composition will always have the same syntax as function composition. >> >> It just so happens that Lens composition with (.) gives us the ability to write person^.job.title which is one of those nice coincidences which looks a bit like C-style object dereference. > > This coincidence is nice because it approximates expectations from > other languages. Unfortunately, this approximation breaks down > quickly in only slightly more complex cases like `func > person^.job.title`, "person^.someFuncProperty someArgument" and > doesn't extend to writing `person.job.title`, leading (imho) to > confusion and an unnatural feel. Yes. It breaks down in the sense that it?s different. So it is, at best a nice coincidence which fosters a little useful intuition and, on closer inspect, also fosters some confusion. On the other hand, the *reasons* that it is different are good reasons; and they lead to a more powerful abstraction because, for example (job.title) is in isolation a valid term, a lens itself, and it can be used with other functions and other contexts and combined in ways you cannot combine things in the C-style languages we started with; things like easily extracting all the titles of all the jobs in a complex structure, or neatly combining together functions which modify several sub properties of different properties, and so on. So it?s a trade-off, but the stuff you win is quite substantial. > Also, I'm not sure why there's a "vote" about this now. As someone > already mentioned, no community approval is needed to *first* > implement it in some way (perhaps using ghc-reskin as suggested by > someone), experiment with it and see if it makes as much sense as some > of us expect. Agreed. No community approval is required to work on experiments, whether they take place as translators or indeed GHC patches for people to try. On the other hand the purpose of posting to the mailing list was to get discussion and, that?s what we?re getting :-) Jules From jschoett at gmail.com Fri Nov 6 19:38:16 2015 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Fri, 6 Nov 2015 11:38:16 -0800 Subject: [cabal] Extract simple static information from PackageDescription Message-ID: <563D01A8.7000405@gmail.com> Hello, I have a simple question regarding GenericPackageDescription/ PackageDescription. I don't understand it from the docs: https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-PackageDescription.html Google and IRC #haskell also didn't help me. I am trying to extract a simple static information out of the cabal file: the hs-source-dirs Is there a way to get this without resolving conditionals, or with minimal effort? (I don't even understand how to resolving conditionals.) I tried it like this: https://gist.github.com/schoettl/b321baa5002ca48a46c5 But here the PackageDescription has no information (library == Nothing, executables == []). I appreciate any help so much. And I will release the program as an open-source example so that it may help other people in future. Thank you, Jakob -- Jakob Sch?ttl E-Mail: jschoett at gmail.com PGP-Key: 0x25055C7F http://jakob.keramik-schoettl.de From lemming at henning-thielemann.de Fri Nov 6 20:04:14 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 6 Nov 2015 21:04:14 +0100 (CET) Subject: [cabal] Extract simple static information from PackageDescription In-Reply-To: <563D01A8.7000405@gmail.com> References: <563D01A8.7000405@gmail.com> Message-ID: On Fri, 6 Nov 2015, Jakob Sch?ttl wrote: > I am trying to extract a simple static information out of the cabal > file: the hs-source-dirs > > Is there a way to get this without resolving conditionals, or with > minimal effort? (I don't even understand how to resolving conditionals.) If you write in a package description: If flag(foo) Hs-Source-Dirs: foo Else Hs-Source-Dirs: bar then Hs-Source-Dirs depends on conditionals. I use this technique in order to select specific modules for Unix and Windows without CPP. How do you want to extract Hs-Source-Dirs without knowing the flag values? From daniel.trstenjak at gmail.com Fri Nov 6 20:37:56 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 6 Nov 2015 21:37:56 +0100 Subject: [cabal] Extract simple static information from PackageDescription In-Reply-To: <563D01A8.7000405@gmail.com> References: <563D01A8.7000405@gmail.com> Message-ID: <20151106203716.GA2035@brick> Hi Jakob, you might like the cabal-lenses[1] library. Getting 'hs-source-dirs' from all sections of the cabal file (library, executable, ...) and evaluating the conditionals in the cabal file (considering the default value of flags and the current platform), you should be able to write: import Control.Lens -- from the lens library import CabalLenses -- from the cabal-lenses library hsSourceDirs :: GenericPackageDescription -> [String] hsSourceDirs pkgDesc = pkgDesc ^.. allBuildInfo . traversed . hsSourceDirsL You can also specify[2] which section you like to read or how flags for the conditionals should be set. If you only need a command line programming for the reading of 'hs-source-dirs', then there's cabal-cargs[3]. The above example: cabal-cargs --only=hs_source_dirs --format=pure Greetings, Daniel [1] https://hackage.haskell.org/package/cabal-lenses-0.4.7 [2] https://hackage.haskell.org/package/cabal-lenses-0.4.5/docs/CabalLenses-Traversals-BuildInfo.html [3] https://hackage.haskell.org/package/cabal-cargs From jschoett at gmail.com Sat Nov 7 02:19:18 2015 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Fri, 6 Nov 2015 18:19:18 -0800 Subject: [cabal] Extract simple static information from PackageDescription In-Reply-To: References: <563D01A8.7000405@gmail.com> Message-ID: <563D5FA6.6000002@gmail.com> On 06.11.2015 12:04, Henning Thielemann wrote: > > On Fri, 6 Nov 2015, Jakob Sch??ttl wrote: > >> I am trying to extract a simple static information out of the cabal >> file: the hs-source-dirs >> >> Is there a way to get this without resolving conditionals, or with >> minimal effort? (I don't even understand how to resolving conditionals.) > > If you write in a package description: > > ? If flag(foo) > ? ? ? Hs-Source-Dirs: foo > ? Else > ? ? ? Hs-Source-Dirs: bar > > then Hs-Source-Dirs depends on conditionals. I use this technique in > order to select specific modules for Unix and Windows without CPP. How > do you want to extract Hs-Source-Dirs without knowing the flag values? Thank you, Henning. I see, I need to handle this conditionals even if I don't have such conditionals and flags in my cabal file. How can I resolve the conditionals? Can I somehow update the GenericPackageDescription i.e. set all flag values and then fetch the complete PackageDescription in using packageDescription? https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Distribution-PackageDescription.html#t:GenericPackageDescription Or are condLibrary, condExecutable, ... the only way to access this data? From wren at community.haskell.org Sat Nov 7 03:49:11 2015 From: wren at community.haskell.org (wren romano) Date: Fri, 6 Nov 2015 22:49:11 -0500 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: <1446679560.1455.10.camel@joachim-breitner.de> References: <1446679560.1455.10.camel@joachim-breitner.de> Message-ID: Hi all, I agree with Joachim Breitner. I've worked with a number of groups with various approaches to collaborative decision making (not just just those called "voting"); and imo the recent upset has nothing to do with the "voting" procedure. I'm not saying we shouldn't consider changes to how we make decisions, just that if/when we do so we should do so for its own sake. The problem isn't with "voting" because, as mentioned repeatedly, we've taken a wide sample of the community and found overwhelming support for the changes. Given the margin of support, choosing other approaches to counting up the size of that margin are unlikely to alter the ordering of "for > against". Given the margin of support, the only thing which could invert that ordering is if we took specific individuals (e.g., those who've publicly "resigned") and considered them to be dictators. Thus, unless the actual proposal is to make those individuals dictators, their opposition is insufficient to counter the support from the rest of the community. No matter how much we dislike the outcomes we got, changing the process of decision making wouldn't've allowed us to avoid those outcomes (again, unless we decided to make certain specific individuals into dictators). The real problem is the growing divide in the community between the "liberals" vs the "conservatives". We could define these groups as those who're willing to break things vs want more stability, or as those who embrace polymorphism vs those who want to minimize mental type inference, or a few other ways I'm sure. How exactly we define the groups doesn't much matter imo; the point is: there are two groups which are growing ever more divergent from one another. Changing how we make decisions isn't going to reconcile these two groups; so long as the groups are widely divergent, any decisions made will upset one or the other. So the real issue at hand is to address the following two questions: (1) how can we reconcile the two groups, reducing the distance between them so as to reduce conflict? (2) supposing the groups cannot be (sufficiently) reconciled, how do we proceed? -- Live well, ~wren From lemming at henning-thielemann.de Sat Nov 7 08:16:44 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 7 Nov 2015 09:16:44 +0100 (CET) Subject: [cabal] Extract simple static information from PackageDescription In-Reply-To: <563D5FA6.6000002@gmail.com> References: <563D01A8.7000405@gmail.com> <563D5FA6.6000002@gmail.com> Message-ID: On Fri, 6 Nov 2015, Jakob Sch?ttl wrote: > Thank you, Henning. I see, I need to handle this conditionals even if I don't > have such conditionals and flags in my cabal file. > > How can I resolve the conditionals? I think, this one should help: https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-PackageDescription-Configuration.html#v:flattenPackageDescription From jschoett at gmail.com Sat Nov 7 18:52:14 2015 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Sat, 7 Nov 2015 10:52:14 -0800 Subject: [cabal] Extract simple static information from PackageDescription In-Reply-To: References: <563D01A8.7000405@gmail.com> <563D5FA6.6000002@gmail.com> Message-ID: <563E485E.6060502@gmail.com> Ah, that's perfect in my case! Thank you! I managed to merge the hs-source-dirs fields "manually": https://gist.github.com/schoettl/b321baa5002ca48a46c5 But flattenPackageDescription seems to do exactly that. Thanks, Jakob On 07.11.2015 00:16, Henning Thielemann wrote: > > On Fri, 6 Nov 2015, Jakob Sch?ttl wrote: > >> Thank you, Henning. I see, I need to handle this conditionals even if >> I don't have such conditionals and flags in my cabal file. >> >> How can I resolve the conditionals? > > I think, this one should help: > https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-PackageDescription-Configuration.html#v:flattenPackageDescription From targen at gmail.com Sat Nov 7 18:57:55 2015 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Sat, 7 Nov 2015 14:27:55 -0430 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: <1446679560.1455.10.camel@joachim-breitner.de> Message-ID: On Fri, Nov 6, 2015 at 11:19 PM, wren romano wrote: > The real problem is the growing divide in the community between the > "liberals" vs the "conservatives". We could define these groups as > those who're willing to break things vs want more stability, or as > those who embrace polymorphism vs those who want to minimize mental > type inference, or a few other ways I'm sure. How exactly we define > the groups doesn't much matter imo; the point is: there are two groups > which are growing ever more divergent from one another. Changing how > we make decisions isn't going to reconcile these two groups; so long > as the groups are widely divergent, any decisions made will upset one > or the other. So the real issue at hand is to address the following > two questions: > > (1) how can we reconcile the two groups, reducing the distance between > them so as to reduce conflict? > (2) supposing the groups cannot be (sufficiently) reconciled, how do we proceed? It may help to have some data to better understand the community's postures. Perhaps we could design a survey with questions on each of these design orientations? I?m not sure at all that it?d be helpful to resolve conflicts, but it?d certainly be interesting to see what clusters of language design ideas come up ? the division you mention certainly seems to be there in some intuitive sense, but our intuition might be flawed in many ways (is polymorphism ?conservative? or ?liberal??). We could include questions relating to the number of public libraries published and maintained, time spent blogging, subscription to various mailing lists, and such, to see how design ideas relate to various forms of community involvement. Of course, results are likely to be awfully biased in many ways if such a survey is not designed, promoted and analyzed very carefully, and it may turn out that arguments based on the resulting data end up being harmful to the community?s discussions. I don?t know; I?m just curious! From gershomb at gmail.com Sat Nov 7 21:02:18 2015 From: gershomb at gmail.com (Gershom B) Date: Sat, 7 Nov 2015 16:02:18 -0500 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: <1446679560.1455.10.camel@joachim-breitner.de> Message-ID: On November 6, 2015 at 10:49:14 PM, wren romano (wren at community.haskell.org) wrote: > Hi all, > > > The real problem is the growing divide in the community between the > "liberals" vs the "conservatives". We could define these groups as > those who're willing to break things vs want more stability, or as > those who embrace polymorphism vs those who want to minimize mental > type inference, or a few other ways I'm sure. How exactly we define > the groups doesn't much matter imo; the point is: there are two groups > which are growing ever more divergent from one another.? I think that a ?two groups? model of the disputes we?ve had lately simplifies too much, and in fact runs the risk of tending to force a bunch of varying motives and concerns into only two buckets, which I worry will increase the contentiousness of discussions rather help to moderate things. Valuing stability for teaching purposes is very different than valuing stability from the standpoint of a library maintainer, for example. And valuing monomorphic definitions of some things is not the same as valuing monomorphic definitions of other things ? or opposing design compromises made in the name of performance, etc. The FTP, while a step forward in many ways, made compromises that opened it up to criticism from many standpoints ? from the correctness standpoint it did strange things to the List module ? from the backwards compatibility standpoint it did not provide perfect backwards compat (especially with warnings taken into account) ? from the performance standpoint it turns out to have introduced at least one unanticipated regression. So no matter your concern, there is somewhere where it did not hit all the marks perfectly. However, this is for the most part because it sought to _mainly_ cover all those marks ? so there is a _decent_ correctness story, and a _decent_ backwards compat story, and a _pretty good_ performance story, etc. But by that token, I hesitate to lump those who had concerns or opposition around the FTP into any particular camp. What I think we can try to ask from people is that they evaluate each proposal, to the extent possible, on _its own merits_ and not as part of any camp they might imagine they are in regarding a long term alignment over ?fast? or ?slow? or ?no? library evolution, or the like. Even if we can?t get 100% consensus (and of course we won?t be able to), a continuing dialog where everyone tries to hear everyone else?s concerns and we try to make sure everyone is comfortable with the direction forward should still be the _goal_. Ideally, we will have less voting and not more, because ideally proposals that we move forward with will have a wide base of support across the board. In my mind, the way to do that is to treat each new library proposal case-by-case and go in willing to hear all sides, rather than prejudging what people?s take may be, why they might have such a take, etc. Cheers, Gershom From wren at community.haskell.org Mon Nov 9 00:39:48 2015 From: wren at community.haskell.org (wren romano) Date: Sun, 8 Nov 2015 19:39:48 -0500 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: <1446679560.1455.10.camel@joachim-breitner.de> Message-ID: On Sat, Nov 7, 2015 at 4:02 PM, Gershom B wrote: > On November 6, 2015 at 10:49:14 PM, wren romano (wren at community.haskell.org) wrote: >> The real problem is the growing divide in the community between the >> "liberals" vs the "conservatives". We could define these groups as >> those who're willing to break things vs want more stability, or as >> those who embrace polymorphism vs those who want to minimize mental >> type inference, or a few other ways I'm sure. How exactly we define >> the groups doesn't much matter imo; the point is: there are two groups >> which are growing ever more divergent from one another. > > I think that a ?two groups? model of the disputes we?ve had lately simplifies too much, and in fact runs the risk of tending to force a bunch of varying motives and concerns into only two buckets, which I worry will increase the contentiousness of discussions rather help to moderate things. Oh, I totally agree. My point wasn't about the number of groups, nor about their organizing concerns; which I'd hoped to make clear by the last sentence quoted above. No, my point was that there is (at least one) rift in the community, that this rift is growing, that the real issue at hand is how we ?as a community? should respond to that rift, and ?perhaps most importantly to the current thread? that changing the procedures of collective decision making will not have an effective impact on that rift since the organizing concerns of the rift (whatever they may be) are not about issues of democratic control and representation but rather about issues of communal identity and mores. -- Live well, ~wren From johnw at newartisans.com Mon Nov 9 14:47:26 2015 From: johnw at newartisans.com (John Wiegley) Date: Mon, 09 Nov 2015 06:47:26 -0800 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: (Gershom B.'s message of "Sat, 7 Nov 2015 16:02:18 -0500") References: <1446679560.1455.10.camel@joachim-breitner.de> Message-ID: >>>>> Gershom B writes: > Even if we can?t get 100% consensus (and of course we won?t be able to), a > continuing dialog where everyone tries to hear everyone else?s concerns and > we try to make sure everyone is comfortable with the direction forward > should still be the _goal_. Ideally, we will have less voting and not more, > because ideally proposals that we move forward with will have a wide base of > support across the board. In my mind, the way to do that is to treat each > new library proposal case-by-case and go in willing to hear all sides, > rather than prejudging what people?s take may be, why they might have such a > take, etc. I very much agree, Gershom. John From malcolm.wallace at me.com Wed Nov 11 10:41:56 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Wed, 11 Nov 2015 10:41:56 +0000 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: References: <1446679560.1455.10.camel@joachim-breitner.de> Message-ID: <060E8E31-A4B6-4363-9CE4-B72356EADB38@me.com> On 7 Nov 2015, at 03:49, wren romano wrote: > The real problem is the growing divide in the community between the > "liberals" vs the "conservatives". We could define these groups as > those who're willing to break things vs want more stability, or as > those who embrace polymorphism vs those who want to minimize mental > type inference, or a few other ways I'm sure. How exactly we define > the groups doesn't much matter imo; I agree with Gershom (and probably Wren too!) that characterising the community discord as a split between two camps is neither accurate nor helpful. But I particularly want us to get away from the idea that those who oppose any particular proposed change, tend to be against language changes in general. It is simply not the case, for any of the recent disputed proposals. Many of the recent objectors are (or have been) themselves language designers, compiler implementers, and indeed made radical language proposals themselves. I do not see any "conservative" party here at all. People who disagree with recent proposals do so with specific technical and sociological arguments. That's it. Some supporters of those proposals might prefer it if they could dismiss the opponents as simply disliking all change, and therefore that their arguments are not worth engaging with. That is a category mistake. Regards, Malcolm From hvriedel at gmail.com Wed Nov 11 11:09:04 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 11 Nov 2015 12:09:04 +0100 Subject: Different kind of votings (Re: Taking a step back) In-Reply-To: <060E8E31-A4B6-4363-9CE4-B72356EADB38@me.com> (Malcolm Wallace's message of "Wed, 11 Nov 2015 10:41:56 +0000") References: <1446679560.1455.10.camel@joachim-breitner.de> <060E8E31-A4B6-4363-9CE4-B72356EADB38@me.com> Message-ID: <87k2pon67j.fsf@gmail.com> On 2015-11-11 at 11:41:56 +0100, Malcolm Wallace wrote: > But I particularly want us to get away from the idea that those who > oppose any particular proposed change, tend to be against language > changes in general. It is simply not the case, for any of the recent > disputed proposals. [...] People who disagree with recent proposals > do so with specific technical and sociological arguments. Could you enumerate the "recent disputed proposals"? It's a bit unclear to me right now which ones are considered in that set. Are all proposals derived from the (real) Burning Bridges (Meta-)Proposal https://mail.haskell.org/pipermail/libraries/2013-May/020046.html contained in that "recent disputed proposals" set? Were there any non-disputed proposals recently? From kili at outback.escape.de Wed Nov 11 21:01:32 2015 From: kili at outback.escape.de (Matthias Kilian) Date: Wed, 11 Nov 2015 22:01:32 +0100 Subject: Conditionally add OpenBSD's pledge(2) call -- but to which library? Message-ID: <20151111210132.GA9018@nutty.outback.escape.de> Hi, I'd like to add the (OpenBSD only) pledge(2) call to some library in our (OpenBSD's) ghc port. See http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2?query=pledge and http://www.openbsd.org/papers/hackfest2015-pledge/index.html for some information of what this is about (and Linux people, please don't feel too offended by that second one ;-)) I'd to this as a patch to ghc in our port, but I'd like to eventually submit a patch to include it (conditionally, only on OpenBSD for now) upstream. But I need some hints *where* to include it. At the moment, I'm considering the unix package (bundled with ghc), and therein, the module System.Posix.Unistd. Even if pledge(2) obviously isn't Posix, it's all about stripping down an API which in large parts conforms to Posix to some subset. Would this be acceptable? Or should I use something like System.OpenBSD.Unistd? In any case, client application using it would always either need some #ifdef or would get patches local to the OpenBSD ports tree. So, any thoughts about this? Please note: just writing a separate package for this wouldn't help much (for OpenBSD ports), because it would require changing cabal dependencies for every client application in addition to other source code patches. Ciao, Kili From carter.schonwald at gmail.com Thu Nov 12 01:27:09 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 11 Nov 2015 20:27:09 -0500 Subject: Conditionally add OpenBSD's pledge(2) call -- but to which library? In-Reply-To: <20151111210132.GA9018@nutty.outback.escape.de> References: <20151111210132.GA9018@nutty.outback.escape.de> Message-ID: its not a posix interface ... so it probably doesn't make sense to do. as best as I understand things, it could be an openbsd only package on hackage, because its really application specific which priveleges should be forsworn, and that can only be articulated at the application toplevel right? On Wed, Nov 11, 2015 at 4:01 PM, Matthias Kilian wrote: > Hi, > > I'd like to add the (OpenBSD only) pledge(2) call to some library in > our (OpenBSD's) ghc port. See > > > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2?query=pledge > > and > > http://www.openbsd.org/papers/hackfest2015-pledge/index.html > > for some information of what this is about (and Linux people, please > don't feel too offended by that second one ;-)) > > I'd to this as a patch to ghc in our port, but I'd like to eventually > submit a patch to include it (conditionally, only on OpenBSD for > now) upstream. But I need some hints *where* to include it. > > At the moment, I'm considering the unix package (bundled with ghc), > and therein, the module System.Posix.Unistd. Even if pledge(2) > obviously isn't Posix, it's all about stripping down an API which > in large parts conforms to Posix to some subset. > > Would this be acceptable? Or should I use something like > System.OpenBSD.Unistd? In any case, client application using it > would always either need some #ifdef or would get patches local to > the OpenBSD ports tree. > > So, any thoughts about this? > > Please note: just writing a separate package for this wouldn't help > much (for OpenBSD ports), because it would require changing cabal > dependencies for every client application in addition to other > source code patches. > > Ciao, > Kili > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Thu Nov 12 07:50:43 2015 From: svenpanne at gmail.com (Sven Panne) Date: Thu, 12 Nov 2015 08:50:43 +0100 Subject: Conditionally add OpenBSD's pledge(2) call -- but to which library? In-Reply-To: <20151111210132.GA9018@nutty.outback.escape.de> References: <20151111210132.GA9018@nutty.outback.escape.de> Message-ID: 2015-11-11 22:01 GMT+01:00 Matthias Kilian : > [...] In any case, client application using it > would always either need some #ifdef or would get patches local to > the OpenBSD ports tree. > > So, any thoughts about this? > > Please note: just writing a separate package for this wouldn't help > much (for OpenBSD ports), because it would require changing cabal > dependencies for every client application in addition to other > source code patches. > This is highly specific to OpenBSD, and (as you mentioned) clients need to be changed, anyway. Therefore cabal dependencies can be changed, too. I don't see why the former should be acceptable while the latter shouldn't. So a separate package seems to be the way to go IMHO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Thu Nov 12 16:09:36 2015 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu, 12 Nov 2015 08:09:36 -0800 Subject: Conditionally add OpenBSD's pledge(2) call -- but to which library? In-Reply-To: <20151111210132.GA9018@nutty.outback.escape.de> References: <20151111210132.GA9018@nutty.outback.escape.de> Message-ID: On Wed, Nov 11, 2015 at 1:01 PM, Matthias Kilian wrote: > Please note: just writing a separate package for this wouldn't help > much (for OpenBSD ports), because it would require changing cabal > dependencies for every client application in addition to other > source code patches. > Changing cabal dependencies is the right thing to do in this case. Any code that will use this function will already need specialized OpenBSD knowledge, so the likelihood of it actually being used is extremely small ? whereas the cost of having a rat's nest of #ifdef usage in clients of core libraries is already well known to be high. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kili at outback.escape.de Thu Nov 12 21:20:49 2015 From: kili at outback.escape.de (Matthias Kilian) Date: Thu, 12 Nov 2015 22:20:49 +0100 Subject: Conditionally add OpenBSD's pledge(2) call -- but to which library? In-Reply-To: References: <20151111210132.GA9018@nutty.outback.escape.de> Message-ID: <20151112212049.GA20542@nutty.outback.escape.de> Hi, On Thu, Nov 12, 2015 at 08:09:36AM -0800, Bryan O'Sullivan wrote: > > Please note: just writing a separate package for this wouldn't help > > much (for OpenBSD ports), because it would require changing cabal > > dependencies for every client application in addition to other > > source code patches. > > > > Changing cabal dependencies is the right thing to do in this case. Any code > that will use this function will already need specialized OpenBSD > knowledge, so the likelihood of it actually being used is extremely small ? > whereas the cost of having a rat's nest of #ifdef usage in clients of core > libraries is already well known to be high. Ok, thank you (and Sven and Carter) for your input. So, on the long term, I'll prepare a separate package when I'm confident that it's actually *useful* for Haskell programs. For now, I'll just keep everything local to the OpenBSD ports tree to experiment a little bit with it. Ciao, Kili From ekmett at gmail.com Fri Nov 13 21:18:38 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 13 Nov 2015 16:18:38 -0500 Subject: Expanding the Core Libraries Committee Message-ID: At present the core libraries committee consists of 7 members: 6 regular members and one ex-officio appointment for the Haskell Platform maintainer. https://wiki.haskell.org/Core_Libraries_Committee The size of this committee was originally selected to be in line with the size of the extant haskell.org committee. During a meeting of the committee last week, we decided it is a bit too small to fulfill the function of adequately representing the broader community while still providing a sufficient institutional memory. Consequently, we've resolved to replace the current Haskell Platform maintainer appointment with 3 additional seats on the committee. This will grow the committee to 9 members. Pleased be advised, membership on the committee is a commitment to a fairly active role. For more information on some the processes surrounding the core libraries, please see the library submissions page on the Haskell wiki: https://wiki.haskell.org/Library_submissions If you are interested in self-nominating for the core libraries committee, please send an email to core-libraries-committee at haskell.org. Thank you for your time and consideration. -Edward Kmett Core Libraries Committee Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Fri Nov 20 17:44:00 2015 From: johnw at newartisans.com (John Wiegley) Date: Fri, 20 Nov 2015 09:44:00 -0800 Subject: ANN: linearscan, linearscan-hoopl 1.0.0 Message-ID: linearscan[1] is a linear scan register allocator[2], written in Coq[3], and extracted to Haskell, as a library for Haskell programs that need to allocate registers. It may also be used directly from Coq. This project is the result of a year-long effort, funded by BAE Systems[4], to explore the application of dependent-types and mathematical verification to a typical engineering task. During the course of construction, several hundred theorems about the code were proven -- although exhaustive coverage was not, in the end, achievable given our time constraints. To remedy this, and as a test of the extraction to Haskell, an optional runtime verifier was built to certify the resulting allocations. Coq 8.5b2[5] was used, as well as the ssreflect[6] library created for that version[7]. linearscan further relies on another library, coq-haskell[8], that I created to facilitate inter-operation between Haskell and Coq. For those using Hoopl[9] to represent program graphs, incorporating linearscan is quite easy: provide an instance of NodeAlloc using the linearscan-hoopl[10] library. Examples of doing so are provided in the test suite for that library. The allocation algorithm implemented by this library was first written in Java by Hanspeter M?ssenb?ck and Michael Pfeiffer[11], and later improved upon by Christian Wimmer[12], whose master's thesis provided the specification for our implementation. John Wiegley BAE Systems Footnotes: [1] http://hackage.haskell.org/package/linearscan [2] http://www.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf [3] https://coq.inria.fr/ [4] http://www.baesystems.com/en-us/our-company/inc-businesses/electronic-systems/research-advanced-development/about-r-and-ad [5] https://coq.inria.fr/news/125.html [6] http://ssr.msr-inria.inria.fr/ [7] http://ssr.msr-inria.inria.fr/FTP/ [8] https://github.com/jwiegley/coq-haskell [9] https://hackage.haskell.org/package/hoopl [10] http://hackage.haskell.org/package/linearscan-hoopl [11] http://dl.acm.org/citation.cfm?id=647478.727924 [12] http://www.christianwimmer.at/Publications/Wimmer04a/ From johnw at newartisans.com Fri Nov 20 21:13:51 2015 From: johnw at newartisans.com (John Wiegley) Date: Fri, 20 Nov 2015 13:13:51 -0800 Subject: [Coq-Club] ANN: linearscan, linearscan-hoopl 1.0.0 In-Reply-To: (Beta Ziliani's message of "Fri, 20 Nov 2015 17:03:33 -0300") References: Message-ID: >>>>> Beta Ziliani writes: > I'd be interested to know what was the outcome of the project from the point > of view of BEA Systems. Is there any report about it? >From BAE's point of view, we gained some industrial perspective. Separately, I have prepared an experience report that is currently seeking a venue. John From gershomb at gmail.com Sun Nov 22 20:53:20 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 22 Nov 2015 15:53:20 -0500 Subject: On parsing Haskell and CPP Message-ID: We've had quite a bit of discussion lately on the difficulty in performing automated processing of Haskell files in the presence of CPP. It turns out that folks have tackled this sort of problem in the world of C, and done some interesting work. I recently ran across SuperC [1], part of the xtc [2] project. In the setting of C they have achieved some impressive results, including as I understand it, the ability to handle the entire Linux kernel across all CPP-recognized configurations. They note that this is a rather tedious to implement task, even once one has recognized the specification of how to do so. However, the paper is good at reviewing related work and simpler techniques as well, and perhaps among them there is a "good enough" set for the CPP used in common Haskell libraries? Cheers, Gershom [1] https://cs.nyu.edu/rgrimm/papers/pldi12.pdf [2] http://cs.nyu.edu/xtc/ From tkn.akio at gmail.com Wed Nov 25 07:37:21 2015 From: tkn.akio at gmail.com (Akio Takano) Date: Wed, 25 Nov 2015 07:37:21 +0000 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87611gpvuf.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: Hi Herbert, On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel wrote: > Hello everybody, > > Based on the feedback gathered from the discussion, the proposal has > been revised to address the raised concerns. The highlights are: > > - A new stretched out transition scheme complying with the recently > enacted 3-release policy (and beyond) has been devised. > > - Unifying `>>`/`*>` has been incorporated into the proposal in the > interest of bundling changes of obviously related changes. > > - Moreover, the feasibility of automatic refactoring tooling was > investigated and resulted in the working `Hs2010To201x` > proof-of-concept. > > Please re-read the revised proposal at > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn > > for more details (or use the Wiki's diffing feature to see what changed > relative to the original revision) if you want to comment, so we can > focus on discussing the actual revised version. I'm sorry to join the discussion so late, but I'd like to mention one thing that doesn't seem to have been brought up. If I understand correctly, this proposal can silently slow down existing programs, sometimes even asymptotically. This applies when a monad is defined with no explicit definition for (>>) nor for (*>). The problem is this: currently, when a Monad instance lacks an explicit definition for (>>), a default implementation based on (>>=) is used. After this proposal, (>>) would be an alias for (*>), for which there is a default implementation based on (<*>). However, at least for some monads, the former is a much better default. [1] is one example where it makes an asymptotic difference in runtime. This type of difference arises when (>>=) has to linearly traverse its LHS, but not its RHS. [1] https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1 I also constructed another example [2]. This is a standard implementation of the strict State monad, except that (>>=) is implemented as a NOINLINE function. You can see that using (*>) in place of (>>) changes the memory usage of the program from constant to linear. The difference here arises from the fact that the default implementation for (>>) can "tail-call" its RHS as long as (>>=) also has this tail-call property, but the default implementation of (*>) cannot. [2] https://gist.github.com/takano-akio/7066c511b60d6ab090c5 In my opinion introducing this kind of performance regression is quite bad. Although I agree that it's frustrating that we are stuck with mapM, mapM_ etc., I believe this should be fixed in a way that doesn't make (>>) slower by default. Regards, Takano Akio > > Also, as per proposal guidelines, and more importantly, for the benefit > of those that lost track of this rather complex discussion, I've tried > to summarize the core of discussion over at > > https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion > > More importantly, based on feedback gathered as well as concerns raised > throughout the discussion, I've revised and extended the proposal into a > "2nd edition MRP". I feel confident the new revised proposal addresses > the major concerns as well as adhering to the recently requested 3-yr > compatibility policy. > > PS: One common oversight I noticed when reviewing the discussion is > that the last-minute proposal addition -- of unifying `>>`/`*>` in > the same vein as `pure`/`return` -- wasn't noticed by many who > joined the debate late. > > However, Unifying `>>`/`*>` and `pure`/`return` are in my opinion > strongly related concerns as they share the same rationale about > correctness issues and it doesn't make sense to do one without the > other. However, the transition time-scales could be set slightly > different to account for the more breaking nature of effectively > changing `>>`'s current default method operational semantics. > > Thanks, > Herbert > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From ekmett at gmail.com Wed Nov 25 19:05:51 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 25 Nov 2015 14:05:51 -0500 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: (>>) becomes slower by default in some cases and drastically faster in others, but since the definition is a member in a class it can actually be fixed by people. In situations where (<*>) is asymptotically more efficient than (>>=) then the default definition in terms of (<*>) wins. Right now, if you run through hackage there are lots of places where (>>) has been manually improved but the (*>) has not -- or vice versa. We have two places where people should apply an optimization and many have only realized that they should optimize one or the other. The key here is to encourage folks to actually define (*>) when it matters. -Edward On Wed, Nov 25, 2015 at 2:37 AM, Akio Takano wrote: > Hi Herbert, > > On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel > wrote: > > Hello everybody, > > > > Based on the feedback gathered from the discussion, the proposal has > > been revised to address the raised concerns. The highlights are: > > > > - A new stretched out transition scheme complying with the recently > > enacted 3-release policy (and beyond) has been devised. > > > > - Unifying `>>`/`*>` has been incorporated into the proposal in the > > interest of bundling changes of obviously related changes. > > > > - Moreover, the feasibility of automatic refactoring tooling was > > investigated and resulted in the working `Hs2010To201x` > > proof-of-concept. > > > > Please re-read the revised proposal at > > > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn > > > > for more details (or use the Wiki's diffing feature to see what changed > > relative to the original revision) if you want to comment, so we can > > focus on discussing the actual revised version. > > I'm sorry to join the discussion so late, but I'd like to mention one > thing that doesn't seem to have been brought up. If I understand > correctly, this proposal can silently slow down existing programs, > sometimes even asymptotically. This applies when a monad is defined > with no explicit definition for (>>) nor for (*>). > > The problem is this: currently, when a Monad instance lacks an > explicit definition for (>>), a default implementation based on (>>=) > is used. After this proposal, (>>) would be an alias for (*>), for > which there is a default implementation based on (<*>). However, at > least for some monads, the former is a much better default. > > [1] is one example where it makes an asymptotic difference in runtime. > This type of difference arises when (>>=) has to linearly traverse its > LHS, but not its RHS. > > [1] https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1 > > I also constructed another example [2]. This is a standard > implementation of the strict State monad, except that (>>=) is > implemented as a NOINLINE function. You can see that using (*>) in > place of (>>) changes the memory usage of the program from constant to > linear. The difference here arises from the fact that the default > implementation for (>>) can "tail-call" its RHS as long as (>>=) also > has this tail-call property, but the default implementation of (*>) > cannot. > > [2] https://gist.github.com/takano-akio/7066c511b60d6ab090c5 > > In my opinion introducing this kind of performance regression is quite > bad. Although I agree that it's frustrating that we are stuck with > mapM, mapM_ etc., I believe this should be fixed in a way that doesn't > make (>>) slower by default. > > Regards, > Takano Akio > > > > > Also, as per proposal guidelines, and more importantly, for the benefit > > of those that lost track of this rather complex discussion, I've tried > > to summarize the core of discussion over at > > > > https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion > > > > More importantly, based on feedback gathered as well as concerns raised > > throughout the discussion, I've revised and extended the proposal into a > > "2nd edition MRP". I feel confident the new revised proposal addresses > > the major concerns as well as adhering to the recently requested 3-yr > > compatibility policy. > > > > PS: One common oversight I noticed when reviewing the discussion is > > that the last-minute proposal addition -- of unifying `>>`/`*>` in > > the same vein as `pure`/`return` -- wasn't noticed by many who > > joined the debate late. > > > > However, Unifying `>>`/`*>` and `pure`/`return` are in my opinion > > strongly related concerns as they share the same rationale about > > correctness issues and it doesn't make sense to do one without the > > other. However, the transition time-scales could be set slightly > > different to account for the more breaking nature of effectively > > changing `>>`'s current default method operational semantics. > > > > Thanks, > > Herbert > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Nov 26 05:47:08 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 26 Nov 2015 00:47:08 -0500 Subject: regex-posix broken on 64 bit windows. Message-ID: Here?s a ticket reporting the issue: https://github.com/haskell/haskell-platform/issues/144 The ticket is on the platform site, but it doesn?t really belong there. On the other hand, there?s no tracker for regex-posix anywhere else. This problem has probably existed for a _long_ time, and I guess has to do with 64-bit incompatibilities in the cbits shipped with the package. I?ve cc?d Chris?Kuklewicz as he is author and maintainer. But I know that he has taken a step back from these packages some time ago. Generally, I would be happy to consider them stable-ish and let the community just migrate away from them or not as open source typically evolves. But regex-posix is pretty widely used still and is in the platform, so I think it is unfortunate that it is broken in this way. It would be great if some interested volunteer were to step up and fix this issue and maybe even offer to take over maintainership (to which I?m sure Chris would have no objection?). (Relatedly, it would be good to have a future discussion on which regex library, if any, is suitable for inclusion in the platform. At this point my inclination would be regex-tdfa-text, although my sense is nearly all the libs are relatively unmaintained at this point?) ?Gershom From tkn.akio at gmail.com Thu Nov 26 08:28:32 2015 From: tkn.akio at gmail.com (Akio Takano) Date: Thu, 26 Nov 2015 08:28:32 +0000 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: On Wed, Nov 25, 2015 at 7:05 PM, Edward Kmett wrote: > (>>) becomes slower by default in some cases and drastically faster in > others, but since the definition is a member in a class it can actually be > fixed by people. This is true, but I think it's much better to avoid breaking people's code in the first place. Also, since the breakage can be silent, one will not always be able to make a fix promptly. > > In situations where (<*>) is asymptotically more efficient than (>>=) then > the default definition in terms of (<*>) wins. You are right. I hadn't thought about this. > > Right now, if you run through hackage there are lots of places where (>>) > has been manually improved but the (*>) has not -- or vice versa. We have > two places where people should apply an optimization and many have only > realized that they should optimize one or the other. > > The key here is to encourage folks to actually define (*>) when it matters. I understand this, but perhaps there is a way to achieve this without slowing down existing code. How about introducing a new warning (enabled with -Wall) that is triggered when a type satisfies the following 3 conditions? 1. The type has a Monad instance and an Applicative instance declared in the same module, with the same set of constraints. 2. (*>) is not defined as (*>) = (>>). i.e. either it has a non-trivial definition or its definition is left out. 3. (>>) is not defined as (>>) = (*>). i.e. either it has a non-trivial definition or its definition is left out. This way, people can be warned when (*>) and (>>) can share an implementation but they don't. - Akio > > -Edward > > On Wed, Nov 25, 2015 at 2:37 AM, Akio Takano wrote: >> >> Hi Herbert, >> >> On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel >> wrote: >> > Hello everybody, >> > >> > Based on the feedback gathered from the discussion, the proposal has >> > been revised to address the raised concerns. The highlights are: >> > >> > - A new stretched out transition scheme complying with the recently >> > enacted 3-release policy (and beyond) has been devised. >> > >> > - Unifying `>>`/`*>` has been incorporated into the proposal in the >> > interest of bundling changes of obviously related changes. >> > >> > - Moreover, the feasibility of automatic refactoring tooling was >> > investigated and resulted in the working `Hs2010To201x` >> > proof-of-concept. >> > >> > Please re-read the revised proposal at >> > >> > https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn >> > >> > for more details (or use the Wiki's diffing feature to see what changed >> > relative to the original revision) if you want to comment, so we can >> > focus on discussing the actual revised version. >> >> I'm sorry to join the discussion so late, but I'd like to mention one >> thing that doesn't seem to have been brought up. If I understand >> correctly, this proposal can silently slow down existing programs, >> sometimes even asymptotically. This applies when a monad is defined >> with no explicit definition for (>>) nor for (*>). >> >> The problem is this: currently, when a Monad instance lacks an >> explicit definition for (>>), a default implementation based on (>>=) >> is used. After this proposal, (>>) would be an alias for (*>), for >> which there is a default implementation based on (<*>). However, at >> least for some monads, the former is a much better default. >> >> [1] is one example where it makes an asymptotic difference in runtime. >> This type of difference arises when (>>=) has to linearly traverse its >> LHS, but not its RHS. >> >> [1] https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1 >> >> I also constructed another example [2]. This is a standard >> implementation of the strict State monad, except that (>>=) is >> implemented as a NOINLINE function. You can see that using (*>) in >> place of (>>) changes the memory usage of the program from constant to >> linear. The difference here arises from the fact that the default >> implementation for (>>) can "tail-call" its RHS as long as (>>=) also >> has this tail-call property, but the default implementation of (*>) >> cannot. >> >> [2] https://gist.github.com/takano-akio/7066c511b60d6ab090c5 >> >> In my opinion introducing this kind of performance regression is quite >> bad. Although I agree that it's frustrating that we are stuck with >> mapM, mapM_ etc., I believe this should be fixed in a way that doesn't >> make (>>) slower by default. >> >> Regards, >> Takano Akio >> >> > >> > Also, as per proposal guidelines, and more importantly, for the benefit >> > of those that lost track of this rather complex discussion, I've tried >> > to summarize the core of discussion over at >> > >> > https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion >> > >> > More importantly, based on feedback gathered as well as concerns raised >> > throughout the discussion, I've revised and extended the proposal into a >> > "2nd edition MRP". I feel confident the new revised proposal addresses >> > the major concerns as well as adhering to the recently requested 3-yr >> > compatibility policy. >> > >> > PS: One common oversight I noticed when reviewing the discussion is >> > that the last-minute proposal addition -- of unifying `>>`/`*>` in >> > the same vein as `pure`/`return` -- wasn't noticed by many who >> > joined the debate late. >> > >> > However, Unifying `>>`/`*>` and `pure`/`return` are in my opinion >> > strongly related concerns as they share the same rationale about >> > correctness issues and it doesn't make sense to do one without the >> > other. However, the transition time-scales could be set slightly >> > different to account for the more breaking nature of effectively >> > changing `>>`'s current default method operational semantics. >> > >> > Thanks, >> > Herbert >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > From hvr at gnu.org Thu Nov 26 08:36:19 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 26 Nov 2015 09:36:19 +0100 Subject: MRP Summary & revised MRP 2ed In-Reply-To: (Akio Takano's message of "Thu, 26 Nov 2015 08:28:32 +0000") References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: <87bnahtaws.fsf@gnu.org> On 2015-11-26 at 09:28:32 +0100, Akio Takano wrote: [...] > I understand this, but perhaps there is a way to achieve this without > slowing down existing code. How about introducing a new warning > (enabled with -Wall) that is triggered when a type satisfies the > following 3 conditions? > > 1. The type has a Monad instance and an Applicative instance declared > in the same module, with the same set of constraints. > 2. (*>) is not defined as (*>) = (>>). i.e. either it has a > non-trivial definition or its definition is left out. > 3. (>>) is not defined as (>>) = (*>). i.e. either it has a > non-trivial definition or its definition is left out. > > This way, people can be warned when (*>) and (>>) can share an > implementation but they don't. Coincidentally, I've recently implemented something similar to that end (but it is *not* enabled via -Wall/-Wcompat by default yet), see https://git.haskell.org/ghc.git/commitdiff/f09f2470a76bb08b7f51d2f5663daa672b86f618 for details. Cheers, hvr From ekmett at gmail.com Thu Nov 26 17:08:49 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 26 Nov 2015 12:08:49 -0500 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: On Thu, Nov 26, 2015 at 3:28 AM, Akio Takano wrote: > > This is true, but I think it's much better to avoid breaking people's > code in the first place. Also, since the breakage can be silent, one > will not always be able to make a fix promptly. > We're not talking about making this change until we can get some warnings in place. That said, in the presence of some existing combinators that have already been generalized from Monad to Applicative you may want to ensure that these definitions have been fixed already. > > > In situations where (<*>) is asymptotically more efficient than (>>=) > then > > the default definition in terms of (<*>) wins. > > You are right. I hadn't thought about this. > > > > > Right now, if you run through hackage there are lots of places where (>>) > > has been manually improved but the (*>) has not -- or vice versa. We have > > two places where people should apply an optimization and many have only > > realized that they should optimize one or the other. > > > > The key here is to encourage folks to actually define (*>) when it > matters. > > I understand this, but perhaps there is a way to achieve this without > slowing down existing code. How about introducing a new warning > (enabled with -Wall) that is triggered when a type satisfies the > following 3 conditions? > > 1. The type has a Monad instance and an Applicative instance declared > in the same module, with the same set of constraints. > 2. (*>) is not defined as (*>) = (>>). i.e. either it has a > non-trivial definition or its definition is left out. > 3. (>>) is not defined as (>>) = (*>). i.e. either it has a > non-trivial definition or its definition is left out. > > This way, people can be warned when (*>) and (>>) can share an > implementation but they don't. This is pretty much what Herbert has been working on, except with the definition biased in favor of (>>) = (*>) being expected, and the other becoming a warning as that definition blows up when and if we later move (>>) out of the class. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkn.akio at gmail.com Fri Nov 27 09:29:09 2015 From: tkn.akio at gmail.com (Akio Takano) Date: Fri, 27 Nov 2015 09:29:09 +0000 Subject: MRP Summary & revised MRP 2ed In-Reply-To: <87bnahtaws.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> <87bnahtaws.fsf@gnu.org> Message-ID: On Thu, Nov 26, 2015 at 8:36 AM, Herbert Valerio Riedel wrote: > On 2015-11-26 at 09:28:32 +0100, Akio Takano wrote: > > [...] > >> I understand this, but perhaps there is a way to achieve this without >> slowing down existing code. How about introducing a new warning >> (enabled with -Wall) that is triggered when a type satisfies the >> following 3 conditions? >> >> 1. The type has a Monad instance and an Applicative instance declared >> in the same module, with the same set of constraints. >> 2. (*>) is not defined as (*>) = (>>). i.e. either it has a >> non-trivial definition or its definition is left out. >> 3. (>>) is not defined as (>>) = (*>). i.e. either it has a >> non-trivial definition or its definition is left out. >> >> This way, people can be warned when (*>) and (>>) can share an >> implementation but they don't. > > Coincidentally, I've recently implemented something similar to that end > (but it is *not* enabled via -Wall/-Wcompat by default yet), see > > https://git.haskell.org/ghc.git/commitdiff/f09f2470a76bb08b7f51d2f5663daa672b86f618 > > for details. Thank you for the information. If I understand correctly, this -fwarn-noncanonical-monad-instances warning doesn't address my concern, because it won't warn about a monad that defines neither (>>) nor (*>) explicitly, which I expect to be a common case. - Akio > > Cheers, > hvr From hvriedel at gmail.com Fri Nov 27 09:42:14 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 27 Nov 2015 10:42:14 +0100 Subject: MRP Summary & revised MRP 2ed In-Reply-To: (Akio Takano's message of "Fri, 27 Nov 2015 09:29:09 +0000") References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> <87bnahtaws.fsf@gnu.org> Message-ID: <87lh9jixs9.fsf@gmail.com> Hi, On 2015-11-27 at 10:29:09 +0100, Akio Takano wrote: [...] > Thank you for the information. If I understand correctly, this > -fwarn-noncanonical-monad-instances warning doesn't address my > concern, because it won't warn about a monad that defines neither (>>) > nor (*>) explicitly, which I expect to be a common case. You're right, from what I've seen the majority of Monad instances don't bother to override (>>)/(*>) currently. But do we really want every Applicative/Monad to explicitly define (*>) (and consequently (>>)=(*>)) ? If so, it seems to be unfortunate that we have an overridable default implementation for (*>)/(>>) in place, as that IMO suggests that you're only supposed to override (*>) in those less common cases where it provides a benefit over the default implementation. What's the point of the default implementation otherwise? -- hvr From tkn.akio at gmail.com Fri Nov 27 09:50:12 2015 From: tkn.akio at gmail.com (Akio Takano) Date: Fri, 27 Nov 2015 09:50:12 +0000 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: On Thu, Nov 26, 2015 at 5:08 PM, Edward Kmett wrote: > On Thu, Nov 26, 2015 at 3:28 AM, Akio Takano wrote: >> >> This is true, but I think it's much better to avoid breaking people's >> code in the first place. Also, since the breakage can be silent, one >> will not always be able to make a fix promptly. > > > We're not talking about making this change until we can get some warnings in > place. I would appreciate such a warning. I was concerned because I didn't find a plan for one on the proposal page. In particular, neither the proposed -fwarn-mrp-compat flag nor the implemented -fwarn-noncanonical-monad-instances flag seemed to protect a programmer from the issue of silent performance regression, when there is no explicit definition for (*>) nor for (>>). > > That said, in the presence of some existing combinators that have already > been generalized from Monad to Applicative you may want to ensure that these > definitions have been fixed already. > >> > >> > In situations where (<*>) is asymptotically more efficient than (>>=) >> > then >> > the default definition in terms of (<*>) wins. >> >> You are right. I hadn't thought about this. >> >> > >> > Right now, if you run through hackage there are lots of places where >> > (>>) >> > has been manually improved but the (*>) has not -- or vice versa. We >> > have >> > two places where people should apply an optimization and many have only >> > realized that they should optimize one or the other. >> > >> > The key here is to encourage folks to actually define (*>) when it >> > matters. >> >> I understand this, but perhaps there is a way to achieve this without >> slowing down existing code. How about introducing a new warning >> (enabled with -Wall) that is triggered when a type satisfies the >> following 3 conditions? >> >> 1. The type has a Monad instance and an Applicative instance declared >> in the same module, with the same set of constraints. >> 2. (*>) is not defined as (*>) = (>>). i.e. either it has a >> non-trivial definition or its definition is left out. >> 3. (>>) is not defined as (>>) = (*>). i.e. either it has a >> non-trivial definition or its definition is left out. >> >> This way, people can be warned when (*>) and (>>) can share an >> implementation but they don't. > > > This is pretty much what Herbert has been working on, except with the > definition biased in favor of (>>) = (*>) being expected, and the other > becoming a warning as that definition blows up when and if we later move > (>>) out of the class. Probably I wasn't clear, but I actually wanted to suggest a warning as a replacement for (the (>>)-related half of) MRP, not as a migration path to it. If the goal is to encourage people to have a good implementation for (*>), it may be achievable with just a warning, with no change to the class hierarchy. That said, I can imagine having a warning like this as a migration path. In that case we could provide a function like thenDefaultByBind :: (Monad m) => m a -> m b -> m b thenDefaultByBind a b = a >>= \_ -> b and give people an option to define (*>) = thenDefaultByBind in their Applicative instances. - Akio > > -Edward From tkn.akio at gmail.com Fri Nov 27 10:18:28 2015 From: tkn.akio at gmail.com (Akio Takano) Date: Fri, 27 Nov 2015 10:18:28 +0000 Subject: MRP Summary & revised MRP 2ed In-Reply-To: <87lh9jixs9.fsf@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> <87bnahtaws.fsf@gnu.org> <87lh9jixs9.fsf@gmail.com> Message-ID: On Fri, Nov 27, 2015 at 9:42 AM, Herbert Valerio Riedel wrote: > You're right, from what I've seen the majority of Monad instances don't > bother to override (>>)/(*>) currently. > > But do we really want every Applicative/Monad to explicitly define (*>) > (and consequently (>>)=(*>)) ? You are right, this indeed seems like a strange thing to require. However I believe that this is much better than silently changing the default definition for (>>) to something that potentially has worse asymptotic behaviors. Of course another option is to keep (>>) in the Monad class. - Akio > > If so, it seems to be unfortunate that we have an overridable default > implementation for (*>)/(>>) in place, as that IMO suggests that you're > only supposed to override (*>) in those less common cases where it > provides a benefit over the default implementation. What's the point of > the default implementation otherwise? > > > -- hvr From ekmett at gmail.com Fri Nov 27 11:09:07 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 27 Nov 2015 06:09:07 -0500 Subject: MRP Summary & revised MRP 2ed (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <87611gpvuf.fsf@gnu.org> Message-ID: I understand that you'd prefer it as a replacement for this plan than as a supplement, but I don't think that that would work all that well. We already have half a dozen combinators in Control.Monad generalized, more are generalizing in 7.10. e.g. We don't want to introduce a 'replicateA_' for instance as the pattern has been to generalize the existing 'M' combinators where possible. What you propose would leave us paralyzed in an difficult to explain middle ground indefinitely. As for making a thenM or thenDefault or thenDefaultByBind to make it easier to define (*>), I'm 100% on board with that. -Edward On Fri, Nov 27, 2015 at 4:50 AM, Akio Takano wrote: > On Thu, Nov 26, 2015 at 5:08 PM, Edward Kmett wrote: > > On Thu, Nov 26, 2015 at 3:28 AM, Akio Takano wrote: > >> > >> This is true, but I think it's much better to avoid breaking people's > >> code in the first place. Also, since the breakage can be silent, one > >> will not always be able to make a fix promptly. > > > > > > We're not talking about making this change until we can get some > warnings in > > place. > > I would appreciate such a warning. I was concerned because I didn't > find a plan for one on the proposal page. In particular, neither the > proposed -fwarn-mrp-compat flag nor the implemented > -fwarn-noncanonical-monad-instances flag seemed to protect a > programmer from the issue of silent performance regression, when there > is no explicit definition for (*>) nor for (>>). > > > > > That said, in the presence of some existing combinators that have already > > been generalized from Monad to Applicative you may want to ensure that > these > > definitions have been fixed already. > > > >> > > >> > In situations where (<*>) is asymptotically more efficient than (>>=) > >> > then > >> > the default definition in terms of (<*>) wins. > >> > >> You are right. I hadn't thought about this. > >> > >> > > >> > Right now, if you run through hackage there are lots of places where > >> > (>>) > >> > has been manually improved but the (*>) has not -- or vice versa. We > >> > have > >> > two places where people should apply an optimization and many have > only > >> > realized that they should optimize one or the other. > >> > > >> > The key here is to encourage folks to actually define (*>) when it > >> > matters. > >> > >> I understand this, but perhaps there is a way to achieve this without > >> slowing down existing code. How about introducing a new warning > >> (enabled with -Wall) that is triggered when a type satisfies the > >> following 3 conditions? > >> > >> 1. The type has a Monad instance and an Applicative instance declared > >> in the same module, with the same set of constraints. > >> 2. (*>) is not defined as (*>) = (>>). i.e. either it has a > >> non-trivial definition or its definition is left out. > >> 3. (>>) is not defined as (>>) = (*>). i.e. either it has a > >> non-trivial definition or its definition is left out. > >> > >> This way, people can be warned when (*>) and (>>) can share an > >> implementation but they don't. > > > > > > This is pretty much what Herbert has been working on, except with the > > definition biased in favor of (>>) = (*>) being expected, and the other > > becoming a warning as that definition blows up when and if we later move > > (>>) out of the class. > > Probably I wasn't clear, but I actually wanted to suggest a warning as > a replacement for (the (>>)-related half of) MRP, not as a migration > path to it. If the goal is to encourage people to have a good > implementation for (*>), it may be achievable with just a warning, > with no change to the class hierarchy. > > That said, I can imagine having a warning like this as a migration > path. In that case we could provide a function like > > thenDefaultByBind :: (Monad m) => m a -> m b -> m b > thenDefaultByBind a b = a >>= \_ -> b > > and give people an option to define > > (*>) = thenDefaultByBind > > in their Applicative instances. > > - Akio > > > > > -Edward > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Sun Nov 29 08:37:19 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 29 Nov 2015 01:37:19 -0700 (MST) Subject: 3 release policy and -Wno-compat Message-ID: <1448786239310-5823202.post@n5.nabble.com> The draft of the 3 release policy has a very strict requirement for warnings, "without causing warnings even when compiled with -Wall". This causes breaking changes to be spread out over a number of years because of deprecation warnings. I propose that "-Wall" in this sentence be replaced with "-Wall -Wno-compat". As we are addressing an audience who wish to suppress a specific category of warnings, it seems reasonable to ask that they make this explicit. (I would also prefer for -Wcompat to be on by default, but that would be another discussion, if and only if this proposal is accepted.) -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From mail at joachim-breitner.de Sun Nov 29 21:05:39 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 29 Nov 2015 22:05:39 +0100 Subject: 3 release policy and -Wno-compat In-Reply-To: <1448786239310-5823202.post@n5.nabble.com> References: <1448786239310-5823202.post@n5.nabble.com> Message-ID: <1448831139.5565.4.camel@joachim-breitner.de> Hi, Am Sonntag, den 29.11.2015, 01:37 -0700 schrieb Jeremy: > The draft of the 3 release policy has a very strict requirement for warnings, > "without causing warnings even when compiled with -Wall". This causes > breaking changes to be spread out over a number of years because of > deprecation warnings. > > I propose that "-Wall" in this sentence be replaced with "-Wall > -Wno-compat". As we are addressing an audience who wish to suppress a > specific category of warnings, it seems reasonable to ask that they make > this explicit. my impression was that "-Wall" would not imply "-Wno-compat", bringing the policy in line with what you intend it to do. And I agree that this is the sensible policy. If that?s not the case, we should consider if it maybe should be the case :-) > (I would also prefer for -Wcompat to be on by default, but that would be > another discussion, if and only if this proposal is accepted.) Indeed a different, but worthwhile discussion. As always, I?m far from having a fixed opinion, but want to note that a lot of code is _not_ library code, and compatibility with one GHC version at a time is all that matters, and (momentarily) irrelevant warnings are annoying. That?s a point in favor of _not_ having it on by default. Greetings, Joachim --? -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ekmett at gmail.com Sun Nov 29 21:25:34 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 29 Nov 2015 16:25:34 -0500 Subject: 3 release policy and -Wno-compat In-Reply-To: <1448786239310-5823202.post@n5.nabble.com> References: <1448786239310-5823202.post@n5.nabble.com> Message-ID: The current design is that -Wcompat will be off by default and includes warnings that are not in -Wall and that we'll be introducing warnings into -Wall when they become actionable under a 3 release policy rather than the more eager approach you are advocating here. So you'll still get warnings before the changes go into effect, but with -Wcompat you get a _lot_ of notice for when you don't care much at all about backwards compatibility, but really want forward compatibility above all. -Edward On Sun, Nov 29, 2015 at 3:37 AM, Jeremy wrote: > The draft of the 3 release policy has a very strict requirement for > warnings, > "without causing warnings even when compiled with -Wall". This causes > breaking changes to be spread out over a number of years because of > deprecation warnings. > > I propose that "-Wall" in this sentence be replaced with "-Wall > -Wno-compat". As we are addressing an audience who wish to suppress a > specific category of warnings, it seems reasonable to ask that they make > this explicit. > > (I would also prefer for -Wcompat to be on by default, but that would be > another discussion, if and only if this proposal is accepted.) > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Nov 30 08:10:04 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 30 Nov 2015 01:10:04 -0700 (MST) Subject: 3 release policy and -Wno-compat In-Reply-To: References: <1448786239310-5823202.post@n5.nabble.com> Message-ID: <1448871004971-5823265.post@n5.nabble.com> Edward Kmett-2 wrote > The current design is that -Wcompat will be off by default and includes > warnings that are not in -Wall and that we'll be introducing warnings into > -Wall when they become actionable under a 3 release policy rather than the > more eager approach you are advocating here. Yes, I understand that that is the current design, and I'm asking whether this could be adjusted. Do we lose anything by the proposed change to the policy, other than authors who want 3-release -Wall-clean code adding an extra flag? (Or maybe I just didn't understand you - are you saying that introducing new warnings are not a bottleneck for any changes?) -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202p5823265.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From ekmett at gmail.com Mon Nov 30 09:59:35 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 30 Nov 2015 04:59:35 -0500 Subject: 3 release policy and -Wno-compat In-Reply-To: <1448871004971-5823265.post@n5.nabble.com> References: <1448786239310-5823202.post@n5.nabble.com> <1448871004971-5823265.post@n5.nabble.com> Message-ID: Regardless of if -Wcompat is on by default or not, the timeline for changes wouldn't change. The only thing that would change is that we'd be asking library authors to use -Wall -Wno-compat which they can't do on old versions of GHC, so it'd become a bigger burden for the lion's share of library maintainers; they'd have to explicitly guard the -Wno-compat flag on the GHC version in their cabal file. At least those who _want_ -Wcompat are explicitly looking forward and it seems right to put the burden on that smaller subset than change the game for every library maintainer. Mind you if a -Wcompat user isn't looking to support old versions, they also have no burden. But, again, switching the default wouldn't gain you any time on any outstanding proposal. -Edward On Mon, Nov 30, 2015 at 3:10 AM, Jeremy wrote: > Edward Kmett-2 wrote > > The current design is that -Wcompat will be off by default and includes > > warnings that are not in -Wall and that we'll be introducing warnings > into > > -Wall when they become actionable under a 3 release policy rather than > the > > more eager approach you are advocating here. > > Yes, I understand that that is the current design, and I'm asking whether > this could be adjusted. Do we lose anything by the proposed change to the > policy, other than authors who want 3-release -Wall-clean code adding an > extra flag? (Or maybe I just didn't understand you - are you saying that > introducing new warnings are not a bottleneck for any changes?) > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202p5823265.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Mon Nov 30 11:13:17 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 30 Nov 2015 04:13:17 -0700 (MST) Subject: 3 release policy and -Wno-compat In-Reply-To: References: <1448786239310-5823202.post@n5.nabble.com> <1448871004971-5823265.post@n5.nabble.com> Message-ID: <1448881997927-5823281.post@n5.nabble.com> Edward Kmett-2 wrote > Regardless of if -Wcompat is on by default or not, the timeline for > changes > wouldn't change. The only thing that would change is that we'd be asking > library authors to use > > -Wall -Wno-compat > > which they can't do on old versions of GHC, so it'd become a bigger burden > for the lion's share of library maintainers; they'd have to explicitly > guard the -Wno-compat flag on the GHC version in their cabal file. > > At least those who _want_ -Wcompat are explicitly looking forward and it > seems right to put the burden on that smaller subset than change the game > for every library maintainer. > > Mind you if a -Wcompat user isn't looking to support old versions, they > also have no burden. > > But, again, switching the default wouldn't gain you any time on any > outstanding proposal. I'm not proposing (at this point) to turn on -Wcompat by default, just to allow warnings that can be turned off with -Wno-compat as an exception to the 3-release policy. Guarding -Wno-compat in .cabal doesn't seem like an excessive burden (one copy-and-paste per package), but if the change won't bring any benefits, it's a moot point (for now). -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202p5823281.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From mail at joachim-breitner.de Mon Nov 30 12:01:33 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 30 Nov 2015 13:01:33 +0100 Subject: 3 release policy and -Wno-compat In-Reply-To: <1448881997927-5823281.post@n5.nabble.com> References: <1448786239310-5823202.post@n5.nabble.com> <1448871004971-5823265.post@n5.nabble.com> <1448881997927-5823281.post@n5.nabble.com> Message-ID: <1448884893.4263.0.camel@joachim-breitner.de> Hi, Am Montag, den 30.11.2015, 04:13 -0700 schrieb Jeremy: > > I'm not proposing (at this point) to turn on -Wcompat by default, just to > allow warnings that can be turned off with -Wno-compat as an exception to > the 3-release policy. do you mean warnings that are _in_ -Wall ? which the warnings in -Wcompat are not? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From voldermort at hotmail.com Mon Nov 30 12:03:34 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 30 Nov 2015 05:03:34 -0700 (MST) Subject: 3 release policy and -Wno-compat In-Reply-To: <1448881997927-5823281.post@n5.nabble.com> References: <1448786239310-5823202.post@n5.nabble.com> <1448871004971-5823265.post@n5.nabble.com> <1448881997927-5823281.post@n5.nabble.com> Message-ID: <1448885014812-5823288.post@n5.nabble.com> More to the point, the policy does allow for telling library authors that they must rewrite their code into something that "may not necessarily be idiomatic". Adding a caveat to .cabal is trivial compared to replacing code with something ugly/clunky/non-idiomatic. An additional issue is that if code is going to break, I would like to change it in one go and be done with it. The current policy of drip-feeding bits and pieces of change requires me to manage the transition piecemeal over a number of years. The very example on the wiki page shows how the same code has to be rewritten twice, over the course of a 5 year transition. The spirit of the 3 release policy is a good compromise. However, the requirement for Wall-and-only-Wall clean compilation feels fanatical. It seems to be creating a straw-man persona, someone who doesn't care how often they have to change their code or what they have to change it into, as long as it compiles Wall-clean with no version-specific flags, and demands that they get exactly what they want without any compromise. -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202p5823288.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From voldermort at hotmail.com Mon Nov 30 12:04:14 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 30 Nov 2015 05:04:14 -0700 (MST) Subject: 3 release policy and -Wno-compat In-Reply-To: <1448884893.4263.0.camel@joachim-breitner.de> References: <1448786239310-5823202.post@n5.nabble.com> <1448871004971-5823265.post@n5.nabble.com> <1448881997927-5823281.post@n5.nabble.com> <1448884893.4263.0.camel@joachim-breitner.de> Message-ID: <1448885054223-5823289.post@n5.nabble.com> Joachim Breitner-2 wrote > do you mean warnings that are _in_ -Wall ? which the warnings in > -Wcompat are not? Yes. -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823202p5823289.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From mail at joachim-breitner.de Mon Nov 30 19:45:44 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 30 Nov 2015 20:45:44 +0100 Subject: 3 release policy and -Wno-compat In-Reply-To: <1448885054223-5823289.post@n5.nabble.com> References: <1448786239310-5823202.post@n5.nabble.com> <1448871004971-5823265.post@n5.nabble.com> <1448881997927-5823281.post@n5.nabble.com> <1448884893.4263.0.camel@joachim-breitner.de> <1448885054223-5823289.post@n5.nabble.com> Message-ID: <1448912744.1725.13.camel@joachim-breitner.de> Am Montag, den 30.11.2015, 05:04 -0700 schrieb Jeremy: > Joachim Breitner-2 wrote > > do you mean warnings that are _in_ -Wall ? which the warnings in > > -Wcompat are not? > > Yes. but then these warnings are not affected by -Wno-compat! (I.e. the warning set "all" and the warning set "compat" are disjoint.) I?m confused. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: