Not sure if this applies here, but withSocketsDo is a huge gotcha. It doesn't affect Linux, but all networking code on BSD(?)/Windows that doesn't use it fails to boot with an unfriendly runtime error (and many people leave it out).
A warning for this would be good. Regards. On Thu, May 23, 2013 at 8:00 PM, <[email protected]> wrote: > Send ghc-devs mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Language level heads-up warnings (David Luposchainsky) > 2. RE: Language level heads-up warnings (Simon Peyton-Jones) > 3. Re: Language level heads-up warnings (David Luposchainsky) > 4. RE: Language level heads-up warnings (Simon Peyton-Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 May 2013 13:36:18 +0200 > From: David Luposchainsky <[email protected]> > Subject: Language level heads-up warnings > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello GHC-Devs, > > The discussion on the libraries mailing list brought up the issue of > breaking compatbility in favour of language evolution/sanitation again; > topics mentioned specifically were Prelude's monomorphic > Foldable/Traversable functions, and the Applicative/Monad issue. > > The main arguments of both sides are these: > > (+) We've been aware of certain unfortunate features of Base for a long > time, and we understand very well how to fix this, and what the > consequences are. > > (-) Changing core language features is something you can never forsee > the consequences of. Breaking compatibility should be avoided at all costs. > > (There's also the argument about beginner friendliness, which is not > backed by evidence, so I'll leave it out here.) > > These two seem contradictory, however they have one almost obvious > common ground: we can already write code right now that will be > unaffected by moving Foldable/Traversable/Applicative+Monad to the > Prelude. Suppose all code is written with this in mind, the change is > trivial. > > Which brings us to the actual problem, namely that code is not written > with this in mind. It is easy to forget about the issue in a practical > setting, regardless of how small the required effort is. Therefore, I'd > like to bring forward the idea of "language level heads-up warnings" > (suggestions for better names appreciated). > > Right now, we can only deprecate functions. When used, GHC informs us > "hey, this will work for now, but better use that in the future". > However, this mechanism is too specialized to tackle the problem above: > for example, there is no way to warn a user about a Monad that is not an > Applicative. > > If the community agrees on making one of the "big" changes, what would > you think of adding warnings about language usage? I'm sure over the > course of a couple of GHC releases, the great majority of libraries > would be modified to rectify these warnings again. If you want an > example: "Warning: Monad without Applicative. This will be enforced in a > future language standard." > > These warnings would have to be hardcoded into GHC, but keep in mind > that this is only for very few, relatively high impact changes, and can > be removed once everything is done. In my opinion, this may be a far > better transitional feature than the alternative (adding compatibility > modules, convincing thousands of developers to listen to the people in > favour of the change, ...). > > Greetings, > David > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 May 2013 13:42:10 +0000 > From: Simon Peyton-Jones <[email protected]> > Subject: RE: Language level heads-up warnings > To: David Luposchainsky <[email protected]>, > "[email protected]" <[email protected]> > Message-ID: > < > 59543203684b2244980d7e4057d5fbc1481a7...@db3ex14mbxc306.europe.corp.microsoft.com > > > > Content-Type: text/plain; charset="us-ascii" > > Yes, I think that if the libraries community thought it was important, I > (or indeed someone else) could add a couple of ad-hoc warnings to GHC > without much work. But you'd all need to be clear and specific about what > warnings were wanted, and they'd need to be easy to check (ie no global > program analysis). > > Simon > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of David Luposchainsky > Sent: 22 May 2013 12:36 > To: [email protected] > Subject: Language level heads-up warnings > > Hello GHC-Devs, > > The discussion on the libraries mailing list brought up the issue of > breaking compatbility in favour of language evolution/sanitation again; > topics mentioned specifically were Prelude's monomorphic > Foldable/Traversable functions, and the Applicative/Monad issue. > > The main arguments of both sides are these: > > (+) We've been aware of certain unfortunate features of Base for a long > time, and we understand very well how to fix this, and what the > consequences are. > > (-) Changing core language features is something you can never forsee the > consequences of. Breaking compatibility should be avoided at all costs. > > (There's also the argument about beginner friendliness, which is not > backed by evidence, so I'll leave it out here.) > > These two seem contradictory, however they have one almost obvious common > ground: we can already write code right now that will be unaffected by > moving Foldable/Traversable/Applicative+Monad to the Prelude. Suppose all > code is written with this in mind, the change is trivial. > > Which brings us to the actual problem, namely that code is not written > with this in mind. It is easy to forget about the issue in a practical > setting, regardless of how small the required effort is. Therefore, I'd > like to bring forward the idea of "language level heads-up warnings" > (suggestions for better names appreciated). > > Right now, we can only deprecate functions. When used, GHC informs us > "hey, this will work for now, but better use that in the future". > However, this mechanism is too specialized to tackle the problem above: > for example, there is no way to warn a user about a Monad that is not an > Applicative. > > If the community agrees on making one of the "big" changes, what would you > think of adding warnings about language usage? I'm sure over the course of > a couple of GHC releases, the great majority of libraries would be modified > to rectify these warnings again. If you want an > example: "Warning: Monad without Applicative. This will be enforced in a > future language standard." > > These warnings would have to be hardcoded into GHC, but keep in mind that > this is only for very few, relatively high impact changes, and can be > removed once everything is done. In my opinion, this may be a far better > transitional feature than the alternative (adding compatibility modules, > convincing thousands of developers to listen to the people in favour of the > change, ...). > > Greetings, > David > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > ------------------------------ > > Message: 3 > Date: Wed, 22 May 2013 15:54:02 +0200 > From: David Luposchainsky <[email protected]> > Subject: Re: Language level heads-up warnings > To: "[email protected]" <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On 2013-05-22 15:42, Simon Peyton-Jones wrote: > > Yes, I think that if the libraries community thought it was > > important, I (or indeed someone else) could add a couple of ad-hoc > > warnings to GHC without much work. But you'd all need to be clear and > > specific about what warnings were wanted, and they'd need to be easy > > to check (ie no global program analysis). > > Simon, > > good to hear that it's worth thinking about. > > I'm not sure what exactly "no global program analysis" means here. Where > would the boundaries of such warnings be? I could imagine problems if > Applicative/Monad are defined in separate packages/modules (although > that may be rare in practice). > > Greetings, > David > > > > ------------------------------ > > Message: 4 > Date: Wed, 22 May 2013 13:59:03 +0000 > From: Simon Peyton-Jones <[email protected]> > Subject: RE: Language level heads-up warnings > To: David Luposchainsky <[email protected]>, > "[email protected]" <[email protected]> > Message-ID: > < > 59543203684b2244980d7e4057d5fbc1481a7...@db3ex14mbxc306.europe.corp.microsoft.com > > > > Content-Type: text/plain; charset="us-ascii" > > I'm just saying that GHC has to be able to check while compiling one > module, ie as now. (It can see details of the things it imports, > obviously, since it needs to know that to compile the module) > > | -----Original Message----- > | From: David Luposchainsky [mailto:[email protected]] > | Sent: 22 May 2013 14:54 > | To: [email protected] > | Cc: Simon Peyton-Jones > | Subject: Re: Language level heads-up warnings > | > | On 2013-05-22 15:42, Simon Peyton-Jones wrote: > | > Yes, I think that if the libraries community thought it was > | > important, I (or indeed someone else) could add a couple of ad-hoc > | > warnings to GHC without much work. But you'd all need to be clear and > | > specific about what warnings were wanted, and they'd need to be easy > | > to check (ie no global program analysis). > | > | Simon, > | > | good to hear that it's worth thinking about. > | > | I'm not sure what exactly "no global program analysis" means here. Where > | would the boundaries of such warnings be? I could imagine problems if > | Applicative/Monad are defined in separate packages/modules (although > | that may be rare in practice). > | > | Greetings, > | David > > > > ------------------------------ > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > > > End of ghc-devs Digest, Vol 117, Issue 43 > ***************************************** >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
