I support acceptance, but only if #475 https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000... is also accepted. The current proposal (#270) affects the use of list and tuple syntax, as this syntax is punned between the term- and type-levels. This fact is illustrated in the examples of #270, but the text in the specification is terse on this front. Note that this proposal dovetails nicely with our Syntactic Unification Principle https://github.com/ghc-proposals/ghc-proposals/blob/master/principles.rst#21.... That principle makes a claim about code that avoid puns, and this proposal enables users to meet that requirement. Thanks, Richard

On Jan 29, 2022, at 10:41 AM, Vitaly Bragilevsky wrote:

Dear Committee,

Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.

https://github.com/ghc-proposals/ghc-proposals/pull/270

https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-...

This proposal was heavily revised since Iavor recommended rejection. As of now, it is quite thin suggesting just a couple of things: - warnings for the code with panning (understood as using same names for both types and values) - a syntax change for import declarations to reflect which names (types or values) are actually imported when importing from libraries relied on punning.

The first change promotes a new style of writing Haskell code without distinguishing types and values and having a single unified namespace. We are already on that road anyway and I don't see any reason not to support this.

The second change allows using an old style with punning. It could lead to doubling import declarations, but I don't think that this is really a problem.

I think the proposal is mature enough so I recommend acceptance.

We can also decide on the actual word used in import declarations (data, value, or pattern). I personally prefer value, but I don't see this issue as something important.

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

Whew! Finally caught up with the PR discussion. I agree with Simon: I don’t think adding style warnings is too dramatic a change, and my experience of introducing people to Haskell has involved a lot of confusion around punning, so I think discouraging punning is probably a good idea. I do also like the import syntax, though, as an idealist, I am hoping that it can eventually be deprecated (once enough code is free of bad puns). Until then, I think this is a nice extra bit of clarity. As someone who habitually decorates everything with explicit forall, standalone kind signatures, explicit deriving strategies, and so on… well, I’m always a fan of extra clarity :-) In short: I like this, and I’m in favour of acceptance. Cheers, Tom

On 29 Jan 2022, at 15:41, Vitaly Bragilevsky wrote:

Dear Committee,

Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.

https://github.com/ghc-proposals/ghc-proposals/pull/270

https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-...

This proposal was heavily revised since Iavor recommended rejection. As of now, it is quite thin suggesting just a couple of things: - warnings for the code with panning (understood as using same names for both types and values) - a syntax change for import declarations to reflect which names (types or values) are actually imported when importing from libraries relied on punning.

The first change promotes a new style of writing Haskell code without distinguishing types and values and having a single unified namespace. We are already on that road anyway and I don't see any reason not to support this.

The second change allows using an old style with punning. It could lead to doubling import declarations, but I don't think that this is really a problem.

I think the proposal is mature enough so I recommend acceptance.

We can also decide on the actual word used in import declarations (data, value, or pattern). I personally prefer value, but I don't see this issue as something important.

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