ok to do reformatting commits?

80 lines when I was just conforming to the existing style. To avoid cluttering my commit with unrelated changes, I decided to fix the
When I was doing a recent patch, I was annoyed by lint errors about lints in a formatting-only commit afterwards. Looking in the archives, I see there was some recent discussion about this, but I didn't see anyone volunteering to just go wrap a bunch of files, or saying that they didn't want anyone to do this (usual reason being cluttering the history, which as a rationale to not do formatting only changes never sat too well with me). Would anyone mind if I went and wrapped a bunch of files, say typecheck/*.hs? This seems simpler than either constant hassling from arc or coming up with more elaborate rules for arc. I would have to make some formatting decisions, so likely to some eyes I would be messing some stuff up, but since there's no real standard that is probably unavoidable.

Thanks for volunteering to do this work, but I'm afraid now is a terrible time to do it. I know of three significant patches that are about to be committed, and your reformatting would cause quite a few merge conflicts. If there is a lull between a feature freeze and a ghc-8.0 fork, that would be the ideal time, to my mind.
That said, I remain unconvinced that a rigid commitment to 80-char lines is in our best interest. My personal vote is to continue to have 80 characters as a guideline but to keep the current practice of allowing programmer discretion.
Richard
On Nov 24, 2015, at 10:14 PM, Evan Laforge
80 lines when I was just conforming to the existing style. To avoid cluttering my commit with unrelated changes, I decided to fix the
When I was doing a recent patch, I was annoyed by lint errors about lints in a formatting-only commit afterwards. Looking in the archives, I see there was some recent discussion about this, but I didn't see anyone volunteering to just go wrap a bunch of files, or saying that they didn't want anyone to do this (usual reason being cluttering the history, which as a rationale to not do formatting only changes never sat too well with me).
Would anyone mind if I went and wrapped a bunch of files, say typecheck/*.hs? This seems simpler than either constant hassling from arc or coming up with more elaborate rules for arc. I would have to make some formatting decisions, so likely to some eyes I would be messing some stuff up, but since there's no real standard that is probably unavoidable. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Tue, Nov 24, 2015 at 7:23 PM, Richard Eisenberg
Thanks for volunteering to do this work, but I'm afraid now is a terrible time to do it. I know of three significant patches that are about to be committed, and your reformatting would cause quite a few merge conflicts. If there is a lull between a feature freeze and a ghc-8.0 fork, that would be the ideal time, to my mind.
Ok, I'll shelve the idea until further notice.
That said, I remain unconvinced that a rigid commitment to 80-char lines is in our best interest. My personal vote is to continue to have 80 characters as a guideline but to keep the current practice of allowing programmer discretion.
In my case it's not so much discretion, but that in the absence of clear guidance, I default to conservatively trying to do whatever the file already does. So there's a bit of contradiction where the local convention says to do one thing but lint says another, and without a tie-breaker I'd go with local convention. In which case best to turn off the lint, and put a guideline in the doc. Also I had no idea about the under_scores means private thing, I just picked what seemed to be prevalent in the surroundings. That would be another good thing to put into https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle

I don’t have a strong view but like Richard I find 80 chars limiting.
I agree that we should resolve this and write down the result on the coding style page
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of
| Richard Eisenberg
| Sent: 25 November 2015 03:23
| To: Evan Laforge

I used to be a 80 chars kind of guy, but working with Simon on the type checker, I did get into the habit of using 120. It has stuck with me. Especially in Haskell, there is a lot of value in that additional space, especially if you like to have descriptive identifiers. (In statement-oriented languages, 80 chars are far less limiting.) Manuel
Simon Peyton Jones
: I don’t have a strong view but like Richard I find 80 chars limiting.
I agree that we should resolve this and write down the result on the coding style page
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Richard Eisenberg | Sent: 25 November 2015 03:23 | To: Evan Laforge
| Cc: ghc-devs@haskell.org | Subject: Re: ok to do reformatting commits? | | Thanks for volunteering to do this work, but I'm afraid now is a | terrible time to do it. I know of three significant patches that are | about to be committed, and your reformatting would cause quite a few | merge conflicts. If there is a lull between a feature freeze and a | ghc-8.0 fork, that would be the ideal time, to my mind. | | That said, I remain unconvinced that a rigid commitment to 80-char | lines is in our best interest. My personal vote is to continue to have | 80 characters as a guideline but to keep the current practice of | allowing programmer discretion. | | Richard | | On Nov 24, 2015, at 10:14 PM, Evan Laforge wrote: | | > When I was doing a recent patch, I was annoyed by lint errors about | >> 80 lines when I was just conforming to the existing style. To | avoid | > cluttering my commit with unrelated changes, I decided to fix the | > lints in a formatting-only commit afterwards. Looking in the | > archives, I see there was some recent discussion about this, but I | > didn't see anyone volunteering to just go wrap a bunch of files, or | > saying that they didn't want anyone to do this (usual reason being | > cluttering the history, which as a rationale to not do formatting | only | > changes never sat too well with me). | > | > Would anyone mind if I went and wrapped a bunch of files, say | > typecheck/*.hs? This seems simpler than either constant hassling | from | > arc or coming up with more elaborate rules for arc. I would have to | > make some formatting decisions, so likely to some eyes I would be | > messing some stuff up, but since there's no real standard that is | > probably unavoidable. | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csi | > | monpj%40064d.mgd.microsoft.com%7c27ba726d65bd49df735d08d2f547c211%7c72 | > | f988bf86f141af91ab2d7cd011db47%7c1&sdata=iGQx%2bYYoG%2bv7xCd6Su%2bzN1L | > gIjx5FxEqmWOSpIbLnjY%3d | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c27ba726d65bd49d | f735d08d2f547c211%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iGQx%2b | YYoG%2bv7xCd6Su%2bzN1LgIjx5FxEqmWOSpIbLnjY%3d _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2015-11-24 22:14 GMT-05:00 Evan Laforge
Would anyone mind if I went and wrapped a bunch of files, say typecheck/*.hs? This seems simpler than either constant hassling from arc or coming up with more elaborate rules for arc. I would have to make some formatting decisions, so likely to some eyes I would be messing some stuff up, but since there's no real standard that is probably unavoidable.
Please don't -- like Richard I have patches in many different branches(although they rarely touch typecheck/) and this will cause so much trouble to us. If Arc linter is causing so much trouble(IMHO it isn't) maybe the solution is to make Arc linter less strict.

2015-11-24 22:14 GMT-05:00 Evan Laforge
When I was doing a recent patch, I was annoyed by lint errors about
80 lines when I was just conforming to the existing style.
I just wanted to mention that I've been using --nolint flag of arc diff lately and it's really great. It doesn't clutter Phabricator diff page with hundreds of "lint error" boxes, unlike plain `arc diff`.
participants (5)
-
Evan Laforge
-
Manuel M T Chakravarty
-
Richard Eisenberg
-
Simon Peyton Jones
-
Ömer Sinan Ağacan