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
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
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 constructor
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
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
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 modularization
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
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
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 named
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-Jones wrote
| -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, 2009-06
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 agree
2009/6/3 Niklas Broberg niklas.brob...@gmail.com:
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
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 with
On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote:
2009/6/3 Niklas Broberg niklas.brob...@gmail.com:
First there's the constructor called TransformListComp, which should
really be named GeneralizedListComp, since the constructor should
describe the extension and not the
15 matches
Mail list logo
