ghc-devs Digest, Vol 117, Issue 43

[Kyle Van Berendonck]

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, <ghc-devs-request at haskell.org> wrote:

> Send ghc-devs mailing list submissions to
>         ghc-devs at haskell.org
>
> 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
>         ghc-devs-request at haskell.org
>
> You can reach the person managing the list at
>         ghc-devs-owner at haskell.org
>
> 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 <dluposchainsky at googlemail.com>
> Subject: Language level heads-up warnings
> To: ghc-devs at haskell.org
> Message-ID: <519CADB2.5080904 at gmail.com>
> 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 <simonpj at microsoft.com>
> Subject: RE: Language level heads-up warnings
> To: David Luposchainsky <dluposchainsky at googlemail.com>,
>         "ghc-devs at haskell.org" <ghc-devs at haskell.org>
> Message-ID:
>         <
> 59543203684B2244980D7E4057D5FBC1481A7305 at 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: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org]
> On Behalf Of David Luposchainsky
> Sent: 22 May 2013 12:36
> To: ghc-devs at haskell.org
> 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
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 22 May 2013 15:54:02 +0200
> From: David Luposchainsky <dluposchainsky at googlemail.com>
> Subject: Re: Language level heads-up warnings
> To: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
> Message-ID: <519CCDFA.40009 at gmail.com>
> 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 <simonpj at microsoft.com>
> Subject: RE: Language level heads-up warnings
> To: David Luposchainsky <dluposchainsky at googlemail.com>,
>         "ghc-devs at haskell.org" <ghc-devs at haskell.org>
> Message-ID:
>         <
> 59543203684B2244980D7E4057D5FBC1481A745D at 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:dluposchainsky at googlemail.com]
> | Sent: 22 May 2013 14:54
> | To: ghc-devs at haskell.org
> | 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
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
> End of ghc-devs Digest, Vol 117, Issue 43
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130523/99f61dc9/attachment.htm>