> 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
_
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
>> 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
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
> 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
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
> 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
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
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
--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
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
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
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'
> 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
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
15 matches
Mail list logo