Yes, I've been thinking about n+k-patterns, too. And datatype contexts! As in: are removal of these features about style? or something else? It's hard to say. So perhaps I walk back my "utterly agnostic about style" comment. (Indeed, the language itself cares deeply about something which most languages consider just style: indentation.)

I don't know how to balance these different aspects of our work, or how to keep everyone (or most) happy while being transparent and honest.

I mean, I personally think punning is bad style, which is why I support this proposal. But I also think that using snake_case for internal identifiers and camelCase for exported ones is a brilliant convention. Does that mean I want a warning when someone fails to do this? No. (Actually, that warning would be absolutely lovely. But I don't think it would have nearly enough support to make it a good idea.)

So maybe we return to saying more verifiable statements: We commit to supporting punning code into perpetuity, and so authors who want to continue to pun are welcome to do so. I'm quite happy committing to that.

Richard

On Sep 7, 2022, at 6:36 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:

Hi,

Am Mittwoch, dem 07.09.2022 um 22:56 +0100 schrieb Simon Peyton Jones:
Maybe the high-level bit here -- the one we might all agree on and
be able to move forward with -- is to say loudly that the GHC
Steering Committee is utterly agnostic on Haskell style, and we
continue to encourage our users to develop, experiment, and have
fun with the full range of programs GHC accepts.


Great -- we could add that to our guidance on the GHC proposals site 

But such a statement does seem to contradict "That statement is all
about how the steering committee will steer and how we might evaluate
future proposal".  If we say we will look on pun-free proposals more
favourably than pun-ful ones, that does seem to be leaning on the
"style" scales, doesn't it?  Is that compatible with being "utterly
agnostic" about style?

I’d also be hesitant to promise to never judge proposals by “style”. 

Removal of NPlusKPatter certainly was a strong statement that this was
bad style (predating the committee, but still).

Discouraging partiality in the language and the libraries, as is
happening on various fronts at the moment (e.g. partial selectors, but
also various CLC discussions) seem to say that “writing Haskell with
partial building blocks is bad style”.

And in this vain I wouldn’t rule out the committee preferring proposals
that work well in code that follows a style that makes Dependent
Haskell work smoothly (e.g., accept #270, but reject a the hypothetical
`newtype Age <- Int` proposal).

(Maybe this isn’t really style but something else, and I misunderstand
what’s said in this thread.)

Cheers,
Joachim

-- 
Joachim Breitner
mail@joachim-breitner.de
http://www.joachim-breitner.de/

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee