On 21/01/2011 13:12, Ian Lynagh wrote:
On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote:
On 20/01/2011 20:22, Axel Simon wrote:
So, again, for this particular extension I suggest that the layout
rule in the standard(s) should be revised -- if I'm mistaken, this will
not break
in place for changing the base language.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Axel Simon
| Sent: 20 January 2011 20:23
| To: Simon Marlow
| Cc: GHC users
| Subject: Re: backward
-boun...@haskell.org] On Behalf Of Axel Simon
| Sent: 20 January 2011 20:23
| To: Simon Marlow
| Cc: GHC users
| Subject: Re: backward compatibility
|
| Hi Simon,
|
| On Jan 20, 2011, at 17:54, Simon Marlow wrote:
|
| The layout fix is this change:
|
|
| http://hackage.haskell.org/trac/ghc/changeset
On 20/01/2011 20:22, Axel Simon wrote:
In the case of the layout bug, I think it might be worth considering
going the other way: adjusting the standard with what ghc has always
done. If I understand correctly, all my code using:
foo = do
some computation
trace I am here $ do
some more
| You've convinced me. The benefit from fixing GHC in this case is
| outweighed by the cost, I think we should revert the change (or at least
| enable RelaxedLayout by default), and propose the change for Haskell
| 2011/2012. Ian, Simon, what do you think?
I'm ok with that
On Fri, Jan 21, 2011 at 10:18:57AM +, Simon Marlow wrote:
On 20/01/2011 20:22, Axel Simon wrote:
So, again, for this particular extension I suggest that the layout
rule in the standard(s) should be revised -- if I'm mistaken, this will
not break other programs.
You've convinced me. The
On 20 January 2011 02:47, John Meacham j...@repetae.net wrote:
Allowing this was a specific feature that was included in ghc on
purpose (as well as the relaxed if/then layout rule in do statements)
So this is definitely a regression.
Ian split this out in this patch:
On Thu, Jan 20, 2011 at 08:14:29AM +, Max Bolingbroke wrote:
On 20 January 2011 02:47, John Meacham j...@repetae.net wrote:
Allowing this was a specific feature that was included in ghc on
purpose (as well as the relaxed if/then layout rule in do statements)
So this is definitely a
package on github has been fixed today.
I'm asking why GHC breaks backward compatibility
(e.g. FlexibleInstances and BangPatterns) and why maintainers of
packages should do boring fixes. What are benefits of such overhead?
--Kazu
___
Glasgow-haskell-users
Am Donnerstag, den 20.01.2011, 23:25 +0900 schrieb 山本和彦:
I'm asking why GHC breaks backward compatibility (e.g.
FlexibleInstances and BangPatterns) and why maintainers of packages
should do boring fixes. What are benefits of such overhead?
Hi,
what are the changes in GHC wrt
Simon Marlow wrote:
Hopefully that explains why sometimes we make breaking changes. If
the
breaking change has a high enough impact, then it becomes worthwhile
to
add backwards compatibility (via warnings / deprecation or whatever).
Of course from the point of view of the user, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/20/11 12:09 , Sittampalam, Ganesh wrote:
Simon Marlow wrote:
judgement as to whether we should spend effort on backwards
compatibility or not. Perhaps we're getting it wrong - so feedback
from
users is always valuable.
From the point of
Hi Simon,
On Jan 20, 2011, at 17:54, Simon Marlow wrote:
The layout fix is this change:
http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d436cf6aac
Another case where GHC was not strictly standards-compliant, and it
was fixed by adding a flag for the extension.
On Thu, Jan 20, 2011 at 05:09:58PM -, Sittampalam, Ganesh wrote:
From the point of view of darcs, which is usually trying to support 2 or 3
GHC versions at a time, one cycle of deprecation makes life a lot simpler.
We do look at warnings and try to fix them, but it's nicer not to have
On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote:
In the case of the layout bug, I think it might be worth considering
going the other way: adjusting the standard with what ghc has always
done.
Anyone can propose language changes - the process is described here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/20/11 21:12 , Ian Lynagh wrote:
On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote:
I therefore think that keeping the number of extensions
to a minimum should be a high priority. It seems that the ghc team is
going overboard with
On 21.01.2011, at 03:12, Ian Lynagh wrote:
On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote:
In the case of the layout bug, I think it might be worth
considering
going the other way: adjusting the standard with what ghc has always
done.
Anyone can propose language changes -
Hello,
I have been using GHC HEAD for some months and am suffering from the
breaks of backward compatibility.
1) MANY packages cannot be complied with GHC HEAD because of lack of
FlexibleInstances and BangPatterns.
2) The network package on github cannot be compiled because the layout
Symposium paper).
Cheers,
Thomas
On Wed, Jan 19, 2011 at 6:32 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hello,
I have been using GHC HEAD for some months and am suffering from the
breaks of backward compatibility.
1) MANY packages cannot be complied with GHC HEAD because of lack
On Wed, Jan 19, 2011 at 6:32 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hello,
I have been using GHC HEAD for some months and am suffering from the
breaks of backward compatibility.
1) MANY packages cannot be complied with GHC HEAD because of lack of
FlexibleInstances and BangPatterns.
2
20 matches
Mail list logo
