| I used to be a 80 column guy, but moved away from that the last years.
| But you are right, there must be an upper limit and, if 80 is a
| problem for code reviews, then it's a reasonable choice.
As laptop screens have successively more horizontal pixels and fewer vertical
pixels, longer lines
On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
| I used to be a 80 column guy, but moved away from that the last years.
| But you are right, there must be an upper limit and, if 80 is a
| problem for code reviews, then it's a reasonable choice.
As laptop
Johan Tibell johan.tib...@gmail.com:
On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
simo...@microsoft.com wrote:
| I used to be a 80 column guy, but moved away from that the last years.
| But you are right, there must be an upper limit and, if 80 is a
| problem for code reviews, then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/07/14 08:57, Johan Tibell wrote:
* Wider screens let you have several Emacs buffers next to each
other. At 80 chars you can have about 2 buffers next to each other
on a 13 screen.
This is my main grief with 100 char lines (which is the
Simon Marlow marlo...@gmail.com:
Austin didn't mention this, so I will: we have a wiki page for style
https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle
It has a pretty clear set of guidelines for imports/exports, for example
(that we don't follow as much as we should).
I'd
On 03/07/2014 09:29, Simon Peyton Jones wrote:
* A *primary* form of consumption is the source code itself. I've found that
Haddock-compliant comments can be rather less readable in source code.
(Eg. CoreSyn.lhs where the #blah# notation coexists uneasily with Note
[blah].)
So I'd be
Austin didn't mention this, so I will: we have a wiki page for style
https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle
It has a pretty clear set of guidelines for imports/exports, for example
(that we don't follow as much as we should).
I'd be in favour of changing .lhs files to
I fully support Austin's proposal. My eyes hurt when I work on 5 files and each
of them is written
in a different style.
Now, to address a few points that were raised.
Is it just for the sake of beauty (not to diminish the importance of beauty)?
* I believe that trailing whitespaces are a
Hi,
Am Donnerstag, den 03.07.2014, 10:44 +0200 schrieb Jan Stolarek:
Now, I understand people who don't want such change because of merge
conflicts. But the truth is there will never be a good moment to
implement such changes because there is always some ongoing
work and outstanding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/07/14 11:13, Joachim Breitner wrote:
So my conclusion is that it?s ok to have the mess in the source
code forever.
I mostly agree. The only way to handle this that I can presently
identify is to agree on some guidelines, put them up on the
And if you are changing 90% of a file for some reason, it
probably doesn't hurt to detab it as well, etc.
I think the reason we still have tabs in the source code is that people usually
don't change 90%
of a file, but 5% or something like that and they feel this is not enough to
justify
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/07/14 17:38, Jan Stolarek wrote:
I think the reason we still have tabs in the source code is that
people usually don't change 90% of a file, but 5% or something
like that and they feel this is not enough to justify detabing of a
whole
On Thu, Jul 3, 2014 at 4:13 AM, Joachim Breitner
m...@joachim-breitner.de wrote:
On the other hand, having a “detab and rename” horizon where merging patches
from
before is much harder, and where git log -L and git blame fail to
work properly would be a hindrance.
Minor point, but you can
[mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 03 July 2014 09:45
| To: ghc-devs@haskell.org
| Subject: Re: RFC: style cleanup guidelines for GHC, and related
| bikeshedding
|
| I fully support Austin's proposal. My eyes hurt when I work on 5 files
| and each of them
On Thu, Jul 3, 2014 at 6:29 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
* Insisting on line comments exclusively, carries a cost. The on-screen
distraction
of line comments, and the nuisance of writing them, is not trivial.
Perhaps it
is bearable, but it's non-zero. See
Hi *,
First off, WARNING: BIKESHEDDING AHEAD.
With that out of the way - today on IRC, there was some discussion
about some stylistic/consistency issues in GHC, and being spurred by
Johans recent proposal for top-level documentation, I figured perhaps
we should beat the drum on this issue as
On Wed, 2 Jul 2014 14:59:13 -0500
Austin Seipp aus...@well-typed.com wrote:
Hi *,
First off, WARNING: BIKESHEDDING AHEAD.
With that out of the way - today on IRC, there was some discussion
about some stylistic/consistency issues in GHC, and being spurred by
Johans recent proposal for
I have mixed feelings on all of this.
First, a disclaimer: I have a significant (~10,000 lines of difference,
perhaps) branch and would be hit hard by this change. (Branch is at
github.com/goldfirere/ghc under the nokinds branch.) That said, if I'm
careful as I'm merging, I could probably make
Hello,
I also have somewhat mixed feelings about this: yes, it would be nice to
get rid of tabs, trailing space, and perhaps even literal files but,
honestly, I don't think that they are any kind of serious blocker to
working on the compiler. Otoh, I'd have to do a bunch of mergining also,
and
19 matches
Mail list logo
