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

[Richard Eisenberg]

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 at 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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220908/8dc484d0/attachment-0001.html>