Re: ghc-devs Digest, Vol 117, Issue 43

23 May 2013

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

Re: ghc-devs Digest, Vol 117, Issue 43

Kyle Van Berendonck