Re: Three patches for cabal

2009-11-09 Thread Niklas Broberg
> I think in the end I'm with Ian on his suggestion that we should allow > the "No" prefix to invert an extension. This would help in this case and > also let us handle things better when the default extensions change. I too agree with this position for the long run. /Niklas _

Re: Three patches for cabal

2009-11-09 Thread Duncan Coutts
On Fri, 2009-11-06 at 01:13 +0100, Niklas Broberg wrote: > > Can someone please comment on these two proposed changes. I agree with > > Niklas but I'm a bit reluctant to apply the patches without at least > > some sign of agreement from someone else. > > > > Deprecating PatternSignatures seems unc

Re: Three patches for cabal

2009-11-05 Thread Niklas Broberg
>> Second there's the constructor NoMonoPatBinds, which actually >> describes the default Haskell 98 behavior, even if GHC has a different >> default. It's GHC's behavior that is the extension, so the constructor >> in cabal should really be named MonoPatBinds. >> >> Also, the PatternSignatures con

Re: Three patches for cabal

2009-06-19 Thread Ian Lynagh
On Wed, Jun 17, 2009 at 10:24:48AM +0100, Duncan Coutts wrote: > > Deprecating PatternSignatures seems uncontroversial, but the > NoMonoPatBinds is potentially controversial. GHC essentially uses > -XMonoPatBinds by default, even in H98 mode, and the user can use > -XNoMonoPatBinds to restore H98

Re: Three patches for cabal

2009-06-18 Thread Niklas Broberg
> hmm, that's annoying.  Is it feasible for the extensions field to allow both > addition and subtraction that override compiler defaults?  (How does it work > in LANGUAGE pragmas -- would NoMonoPatBinds still work in one of them?) It would only work during the period of deprecation, and would obv

Re: Three patches for cabal

2009-06-18 Thread Isaac Dupree
Duncan Coutts wrote: In practise, since ghc uses MonoPatBinds by default it'd mean that people who want to get back to H98 would need to use: ghc-options: -XNoMonoPatBinds Because the extensions field is additive, not subtractive. Using the name MonoPatBinds allows other compilers to implemen

Re: Three patches for cabal

2009-06-18 Thread Niklas Broberg
> In general I think there is a reasonable case for special treatment for > exceptions to H98 that have been accepted for haskell-prime. I'm not sure I agree with this. I'm not involved in the H' process, but it was my impression that the general state of affairs was a move towards a modularizatio

RE: Three patches for cabal

2009-06-18 Thread Sittampalam, Ganesh
Duncan Coutts wrote: > Niklas's and my point is > that the list of language extensions in Language.Haskell.Exceptions > are differences from H98 so it should be MonoPatBinds to get the > difference not NoMonoPatBinds to restore H98. > In practise, since ghc uses MonoPatBinds by default it'd

Re: Three patches for cabal

2009-06-17 Thread Duncan Coutts
On Wed, 2009-06-03 at 16:41 +0200, Niklas Broberg wrote: > Second there's the constructor NoMonoPatBinds, which actually > describes the default Haskell 98 behavior, even if GHC has a different > default. It's GHC's behavior that is the extension, so the constructor > in cabal should really be nam

RE: Three patches for cabal

2009-06-05 Thread Simon Peyton-Jones
--Original Message- | From: Duncan Coutts [mailto:duncan.cou...@worc.ox.ac.uk] | Sent: 05 June 2009 01:31 | To: Simon Peyton-Jones | Cc: Max Bolingbroke; Niklas Broberg; GHC-users; Haskell Libraries | Subject: RE: Three patches for cabal | | On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-J

RE: Three patches for cabal

2009-06-04 Thread Duncan Coutts
On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote: > I'd be quite happy to rename the flag to GeneralisedisedListComp, and > clarify the user manual. Would that suit everyone? > > I suppose the alternative is to leave it as TransformListComp, and > document that fact. But I rather agre

RE: Three patches for cabal

2009-06-04 Thread Simon Peyton-Jones
Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Duncan Coutts | Sent: 04 June 2009 00:38 | To: Max Bolingbroke | Cc: GHC-users; Haskell Libraries | Subject: Re: Three patches for cabal | | On Wed, 20

Re: Three patches for cabal

2009-06-03 Thread Duncan Coutts
On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote: > 2009/6/3 Niklas Broberg : > > First there's the constructor called TransformListComp, which should > > really be named GeneralizedListComp, since the constructor should > > describe the extension and not the implementation scheme. > > It'

Re: Three patches for cabal

2009-06-03 Thread Niklas Broberg
> It's called TransformListComp because the "then f" syntax transforms a > list using f (which has type [a] -> [a]) - not because the > implementation works by transformation or anything like that! We > considered but rejected GeneralizedListComp because it's too vague - > what if someone comes up

Re: Three patches for cabal

2009-06-03 Thread Max Bolingbroke
2009/6/3 Niklas Broberg : > First there's the constructor called TransformListComp, which should > really be named GeneralizedListComp, since the constructor should > describe the extension and not the implementation scheme. It's called TransformListComp because the "then f" syntax transforms a li