<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I support acceptance, but only if <a href="https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst" class="">#475</a> is also accepted.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Note that this proposal dovetails nicely with our <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/principles.rst#21syntax" class="">Syntactic Unification Principle</a>. That principle makes a claim about code that avoid puns, and this proposal enables users to meet that requirement.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Richard</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2022, at 10:41 AM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" class="">bravit111@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear Committee,<br class=""><br class="">Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.<br class=""><br class=""><a href="https://github.com/ghc-proposals/ghc-proposals/pull/270" class="">https://github.com/ghc-proposals/ghc-proposals/pull/270</a><br class=""><br class="">https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md<br class=""><br class="">This proposal was heavily revised since Iavor recommended rejection.<br class="">As of now, it is quite thin suggesting just a couple of things:<br class="">- warnings for the code with panning (understood as using same names<br class="">for both types and values)<br class="">- a syntax change for import declarations to reflect which names<br class="">(types or values) are actually imported when importing from libraries<br class="">relied on punning.<br class=""><br class="">The first change promotes a new style of writing Haskell code without<br class="">distinguishing types and values and having a single unified namespace.<br class="">We are already on that road anyway and I don't see any reason not to<br class="">support this.<br class=""><br class="">The second change allows using an old style with punning. It could<br class="">lead to doubling import declarations, but I don't think that this is<br class="">really a problem.<br class=""><br class="">I think the proposal is mature enough so I recommend acceptance.<br class=""><br class="">We can also decide on the actual word used in import declarations<br class="">(data, value, or pattern). I personally prefer value, but I don't see<br class="">this issue as something important.<br class=""><br class="">Vitaly<br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class="">ghc-steering-committee@haskell.org<br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></div></blockquote></div><br class=""></div></body></html>