<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="">Like many on this list, I've never been bothered by the existing syntax. But I am swayed by experienced folks who very much want this.<div class=""><br class=""></div><div class="">I like Vitaly's idea of opening the door to future changes. I think there is more improvement to be found in our import/export syntax than just this one change, and so if we have a generic enough language extension, it allows us to consider smallish syntax changes without new language extensions in the future. `FlexibleImports` is as good a name as any, I think.</div><div class=""><br class=""></div><div class="">As to the annoyance about adding language extensions: what if we issue a *warning*, not an error, when the user writes a program without specifying the extension? This warning would be on by default (but could, naturally, be suppressed). I'd be comfortable with expanding this treatment by identifying a set of "benign" extensions. Each benign extension would have an accompanying warning, e.g., -Wmissing-FlexibleInstances. These would all be on by default, suppressed with either, e.g., -XFlexibleInstances or -Wno-missing-FlexibleInstances. (Interestingly, the semantics of -XFlexibleInstances and -Wno-missing-FlexibleInstances is identical. Hmm.)</div><div class=""><br class=""></div><div class="">Definition: A *benign* extension is one that, when enabled, strictly increases the set of programs GHC accepts. It never changes the meaning of any program that was accepted without the extension.</div><div class=""><br class=""></div><div class="">I don't feel strongly on this warning idea, but I wanted to throw it out there.</div><div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This never bothered me personally, but I have no strong feeling about it either way. </div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" class="">bravit111@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hello, <div class=""><br class=""></div><div class="">I am in favor of this proposal. As for the name of the extension, my suggestion is 'FlexibleImports', then we could allow even more flexibility in import declarations in the future. Anyway, I am also ok with the current versions (although the shorter the better).</div><div class=""><br class=""></div><div class="">Regards, </div><div class="">Vitaly<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank" class="">marlowsd@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">Proposal #190 is about accepting the syntax</div><div class=""><br class=""></div><div class=""> import A.B.C qualified</div><div class=""><br class=""></div><div class="">instead of (or in addition to) the existing syntax</div><div class=""><br class=""></div><div class=""> import qualified A.B.C</div><div class=""><br class=""></div><div class="">I think it's widely accepted that the original syntax was a mistake. I don't need to rehash the rationale for the change here, iit's described pretty well in the proposal and elaborated in the discussion.</div><div class=""><br class=""></div><div class="">The question for us is really: is it worth changing? There are costs:</div><div class="">- A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)</div><div class="">- new code using the extension doesn't compile with older compilers</div><div class="">- all the existing code in the world uses the old convention</div><div class="">- etc.<br class=""></div><div class=""><br class=""></div><div class="">Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.</div><div class=""><br class=""></div><div class="">Personally, the current syntax annoys me almost every day. It's already a small cost on everyone, and I think we need to move forwards even if there are costs in migrating. So, I'm going to recommend that we accept this proposal.</div><div class=""><br class=""></div><div class="">We might want to reconsider the name of the extension: <code class="">QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?</code></div><div class=""><code class=""><br class=""></code></div><div class=""><code class="">Cheers</code></div><div class=""><code class="">Simon</code></div><div class=""><code class=""><br class=""></code></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Committee,<br class="">
<br class="">
this is your secretary speaking:<br class="">
<br class="">
Module qualified syntax<br class="">
has been proposed by Shayne Fletcher<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/190" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/190</a><br class="">
<a href="https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst" rel="noreferrer" target="_blank" class="">https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst</a><br class="">
<br class="">
Simon Marlow has already volunteered to shepherd.<br class="">
<br class="">
Please reach consensus as described in<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br class="">
I suggest you make a recommendation, in a new e-mail thread with the<br class="">
proposal number in the subject, about the decision, maybe point out<br class="">
debatable points, and assume that anyone who stays quiet agrees with<br class="">
you.<br class="">
<br class="">
Thanks,<br class="">
Joachim<br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div></div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>