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 another list comprehension generalisation in the future?

I see, my mistake in interpreting the naming. However, I really don't agree this is a good choice. This feature is documented and refered to all over the place as general(ised) list comprehension, whereas a google search for either of the terms "transform list comprehension" or "tranformation list comprehension", with quotes, returns zilch (and without quotes returns nothing Haskellish). It seems clear to me that we need to either do the change I propose, which I think goes best with the principle of least surprise, or rewrite the GHC documentation at the very least. I can agree that generalised list comprehension could be a bit too vague to be future sensitive - but I'd rather cross that bridge when we get there! Cheers, /Niklas

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 that GeneralisedListComp fits the literature better. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@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-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'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 another list comprehension | > generalisation in the future? | | In that case can the documentation, eg in the ghc user guide[1] be | updated to use the new name. It's jolly confusing to go looking for the | extension name corresponding to the extension. The ghc user guide | section on it calls it generalised and mentions no flag or extension | name. We initially thought that the extension had never been registered | and I only found it by accident when looking in the reference section of | the ghc user guide on flag names[2] I noticed that "transform list | comprehensions" actually links to the section on generalise list | comprehensions. | | Duncan | | [1] | http://haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#genera... | list-comprehensions | [2] | http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id29... | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Since there has been little comment on this, my preliminary conclusion is that no one cares much what the flag is called. So I've left the flag unchanged, but make the manual mention it in the right place. If pressure builds to change the flag name, I'm happy to do so. Simon | -----Original Message----- | From: Duncan Coutts [mailto:duncan.coutts@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: | > 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 that GeneralisedListComp fits | > the literature better. | | Looking at the paper, it doesn't really give it any specific name. | Perhaps is a good thing because we can change the ghc user guide | relatively easily, but not published papers. | | I appreciate Max's point that GeneralisedListComp is a bit vague, though | TransformListComp doesn't really speak to me. I would not (and did not) | guess it has any relation to the extension in question. My only other | suggestion is QueryListComp or GeneralisedQueryListComp (bikeshed | dangers approaching...). | | The main point is that the docs and the extension name should be | consistent (and should refer to each other). | | Duncan |

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 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 implement it without it having to be the default.

In general I think there is a reasonable case for special treatment for exceptions to H98 that have been accepted for haskell-prime. However in this case the idea of having monomorphic pattern bindings has been rejected from haskell-prime, so I'm in favour of calling it 'MonoPatBinds'. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

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 implement it without it having to be the default.

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?) -Isaac

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 behaviour. 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 mean that people who want to get back to H98 would need to use:

ghc-options: -XNoMonoPatBinds

I think that Cabal should allow any extension to be listed as either Foo or NoFoo, just as GHC does in a -X flag or a LANGUAGE pragma. This will also be useful if we get extension groups like Haskell'2009 and Haskell'2010, where you might want to say something like: Haskell'2010 minus ExistentialQuantification Thanks Ian

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 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 behaviour. 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 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 implement it without it having to be the default.

I had a look at the source for cabal HEAD and was surprised to see that this stuff had fallen by the wayside. What's holding it up? I can't imagine that anyone would be against the deprecation of PatternSignatures at least.

I'd forgotten they were separate patches. I've applied the PatternSignatures one since that is indeed uncontroversial. I don't think the discussion on the other ones were conclusive yet. 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. Duncan