
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