Re: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept

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 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 mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

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