I support acceptance, but only if #475 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. 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 <bravit111@gmail.com> 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-pun-free-code.md

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