[ghc-steering-committee] -Wmissing-language (Was: Module qualified syntax)

Fri Mar 8 19:20:50 UTC 2019

I don't think this is necessary. Managing language extensions is not that hard, and can be trivial with good tooling (which at least some editors already have).

That being said, I suspect that most if not all benign extensions would be good candidates for inclusion in the next language standard.

On Fri, Mar 8, 2019, at 12:52, Joachim Breitner wrote:
> Hi,
> 
> let’s see. Currently, we issue an *error*
> 
>  error: Illegal lambda-case (use -XLambdaCase)
> 
> your idea would turn that into a warning
> 
>  warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase)
> 
> It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are 
> essentially the same.
> 
> 
> 
> But how about we add a single warning category:
> 
>  warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase)
> 
> We could even leave the default as 
> 
>  -Werror=missing-langauge
> 
> matching existing behavior. People who want to play around more 
> liberally can use
> 
>  -Wwarn=missing-language
> 
> and get notified which extensions they might want (maybe a good default
> for ghci?), and those who really don't care can use
> 
>  -Wno-missing-language
> 
> 
> And then the question is: Do this only only for benign extensions? Only
> for those where we can easily issue warnings? For all?
> 
> 
> Not sure how useful it is, but it might be.
> 
> Cheers,
> Joachim
> 
> 
> Am Freitag, den 08.03.2019, 12:37 -0500 schrieb 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> 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> 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> 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/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
> > > > > > 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
> > > > > > http://www.joachim-breitner.de/
> > > > > > 
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > ghc-steering-committee at haskell.org
> > > > > > 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
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > 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
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> Attachments:
> * signature.asc