<div dir="ltr"><div dir="ltr">On Fri, 8 Mar 2019 at 17:52, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
let’s see. Currently, we issue an *error*<br>
<br>
   error: Illegal lambda-case (use -XLambdaCase)<br>
<br>
your idea would turn that into a warning<br>
<br>
   warning [-Wmissing-LambdaCase] : Illegal lambda-case (use -XLambdaCase)<br>
<br>
It is odd that now -Wno-missing-LambdaCase and -XLambdaCase are essentially the same.<br>
<br>
<br>
<br>
But how about we add a single warning category:<br>
<br>
   warning [-Wmissing-langauge] : Illegal lambda-case (use -XLambdaCase)<br>
<br>
We could even leave the default as <br>
<br>
   -Werror=missing-langauge<br>
<br>
matching existing behavior. People who want to play around more liberally can use<br>
<br>
   -Wwarn=missing-language<br>
<br>
and get notified which extensions they might want (maybe a good default<br>
for ghci?), and those who really don't care can use<br>
<br>
   -Wno-missing-language<br></blockquote><div><br></div><div>So {-# OPTIONS_GHC -Wno-missing-language #-} at the top of the file would essentially exempt the file from having to specify LANGUAGE pragmas for some the extensions that it uses, which is the same as saying that some extensions don't need LANGUAGE pragmas. I think that would be a shame, because we lose all the nice properties that we get from being strict about requiring LANGUAGE pragmas for extensions.  Even -Wwarn=missing-language would be dangerous in the same sense.</div><div><br></div><div>I'm not a fan of this.  I like warnings for unused extension pragmas, but not for missing pragmas.<br></div><div><br></div><div>Incidentally, having extensions that we add to later, like FlexiableImports, is also somewhat dodgy because the same extension pragma means different things depending on which compiler version you're using. Perhaps being completely strict about this is not feasible in general (we make small changes to extensions a lot, and it would be silly to make a new flag each time), but it's an area we should be careful about. If we add to FlexibleImports, and you're using an older version of the compiler that doesn't support whatever addition we made to it, we'll get a parse error instead of a "unsupported extension" diagnostic.<br></div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
And then the question is: Do this only only for benign extensions? Only<br>
for those where we can easily issue warnings? For all?<br>
<br>
<br>
Not sure how useful it is, but it might be.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
Am Freitag, den 08.03.2019, 12:37 -0500 schrieb Richard Eisenberg:<br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.)<br>
> <br>
> 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.<br>
> <br>
> I don't feel strongly on this warning idea, but I wanted to throw it out there.<br>
> <br>
> Richard<br>
> <br>
> > On Mar 8, 2019, at 11:59 AM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<br>
> > <br>
> > This never bothered me personally, but I have no strong feeling about it either way. <br>
> > <br>
> > On Fri, Mar 8, 2019 at 6:30 AM Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:<br>
> > > Hello, <br>
> > > <br>
> > > 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).<br>
> > > <br>
> > > Regards, <br>
> > > Vitaly<br>
> > > <br>
> > > On Fri, Mar 8, 2019 at 11:32 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br>
> > > > Proposal #190 is about accepting the syntax<br>
> > > > <br>
> > > >   import A.B.C qualified<br>
> > > > <br>
> > > > instead of (or in addition to) the existing syntax<br>
> > > > <br>
> > > >   import qualified A.B.C<br>
> > > > <br>
> > > > 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.<br>
> > > > <br>
> > > > The question for us is really: is it worth changing? There are costs:<br>
> > > > - A new extension flag, which itself has costs (extra documentation, a new thing that people need to understand)<br>
> > > > - new code using the extension doesn't compile with older compilers<br>
> > > > - all the existing code in the world uses the old convention<br>
> > > > - etc.<br>
> > > > <br>
> > > > Reasonable people can differ here. The discussion on the proposal has representatives from both sides of the camp.<br>
> > > > <br>
> > > > 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.<br>
> > > > <br>
> > > > We might want to reconsider the name of the extension: QualifiedImportsPostpositive seems like a mouthful. Perhaps ImportQualifiedPost is enough?<br>
> > > > <br>
> > > > Cheers<br>
> > > > Simon<br>
> > > > <br>
> > > > On Mon, 4 Mar 2019 at 12:09, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> > > > > Dear Committee,<br>
> > > > > <br>
> > > > > this is your secretary speaking:<br>
> > > > > <br>
> > > > > Module qualified syntax<br>
> > > > > has been proposed by Shayne Fletcher<br>
> > > > > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/190" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/190</a><br>
> > > > > <a href="https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst" rel="noreferrer" target="_blank">https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-syntax/proposals/0000-module-qualified-syntax.rst</a><br>
> > > > > <br>
> > > > > Simon Marlow has already volunteered to shepherd.<br>
> > > > > <br>
> > > > > Please reach consensus as described in<br>
> > > > > <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
> > > > > I suggest you make a recommendation, in a new e-mail thread with the<br>
> > > > > proposal number in the subject, about the decision, maybe point out<br>
> > > > > debatable points, and assume that anyone who stays quiet agrees with<br>
> > > > > you.<br>
> > > > > <br>
> > > > > Thanks,<br>
> > > > > Joachim<br>
> > > > > -- <br>
> > > > > Joachim Breitner<br>
> > > > >   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> > > > >   <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
> > > > > <br>
> > > > > _______________________________________________<br>
> > > > > ghc-steering-committee mailing list<br>
> > > > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > > <br>
> > > > _______________________________________________<br>
> > > > ghc-steering-committee mailing list<br>
> > > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > <br>
> > > _______________________________________________<br>
> > > ghc-steering-committee mailing list<br>
> > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > <br>
> > _______________________________________________<br>
> > ghc-steering-committee mailing list<br>
> > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> <br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>