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 well
On Wed, 2 Jul 2014 14:59:13 -0500
Austin Seipp 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 top-level document
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 mak
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 I
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 branc
-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 deta
-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
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 use "git blame -w"
arations] in TcTyClsDecls.
| -Original Message-
| From: ghc-devs [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 supp
On Thu, Jul 3, 2014 at 6:29 PM, Simon Peyton Jones
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 example below.
I thi
> The on-screen distraction of line comments, and the nuisance of writing them,
> is not
> trivial.
Well, I don't consider one-line comments to be distracting at all. To each his
own, I guess.,
though your opinion on this is more important than mine.
But I don't agree that writing one-line com
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 n
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 .h
Simon Marlow :
> 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
| 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
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 screens have success
Johan Tibell :
>
> On Thu, Jul 17, 2014 at 8:40 AM, Simon Peyton Jones
> 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
-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
20 matches
Mail list logo
