[ghc-steering-committee] #190: Module qualified syntax, recommendation: accept

[Richard Eisenberg]

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.

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.

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.)

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.

I don't feel strongly on this warning idea, but I wanted to throw it out there.

Richard

> On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> This never bothered me personally, but I have no strong feeling about it either way. 
> 
> On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <bravit111 at gmail.com <mailto:bravit111 at gmail.com>> wrote:
> Hello, 
> 
> 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).
> 
> Regards, 
> Vitaly
> 
> On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> Proposal #190 is about accepting the syntax
> 
>   import A.B.C qualified
> 
> instead of (or in addition to) the existing syntax
> 
>   import qualified A.B.C
> 
> 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.
> 
> The question for us is really: is it worth changing? There are costs:
> - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)
> - new code using the extension doesn't compile with older compilers
> - all the existing code in the world uses the old convention
> - etc.
> 
> Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.
> 
> 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.
> 
> We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?
> 
> Cheers
> Simon
> 
> On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Module qualified syntax
> has been proposed by Shayne Fletcher
> https://github.com/ghc-proposals/ghc-proposals/pull/190 <https://github.com/ghc-proposals/ghc-proposals/pull/190>
> https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst <https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst>
> 
> Simon Marlow has already volunteered to shepherd.
> 
> Please reach consensus as described in
> https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> I suggest you make a recommendation, in a new e-mail thread with the
> proposal number in the subject, about the decision, maybe point out
> debatable points, and assume that anyone who stays quiet agrees with
> you.
> 
> Thanks,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/04a4048b/attachment-0001.html>