Three patches for cabal

[Niklas Broberg]

(Trying again since my previous patches were too big for the list.)

While doing a survey[1] of the extensions registered with Cabal, I
came across two warts in the list of constructors, and one constructor
that should be deprecated.

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.

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 has been deprecated in GHC and
superceded by ScopedTypeVariables.

The attached patches (three in one file) adds the proposed new
constructors, deprecates the old ones, and adds documentation.

Cheers,

/Niklas


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Max Bolingbroke-2]

2009/6/3 Niklas Broberg <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?

Max
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote:

> 2009/6/3 Niklas Broberg <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#generalised-list-comprehensions
[2]
http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2949842

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Peyton-Jones]

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@... [mailto:glasgow-haskell-users-
| bounces@...] 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 <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#generalised-
| list-comprehensions
| [2]
| http://haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id2949842
|
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@...
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Simon Peyton-Jones]

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@...]
| 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
|

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 named MonoPatBinds.
>
> Also, the PatternSignatures constructor has been deprecated in GHC and
> superceded by ScopedTypeVariables.
>
> The attached patches (three in one file) adds the proposed new
> constructors, deprecates the old ones, and adds documentation.

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.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 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 
 ===============================================================================
 
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 modularization of the standard, so instead of a single
monolithic Haskell' language we would have a series of blessed
addendums like we already have with e.g. the hierarchical module
namespace or FFI. If that's the case then having each of those
addendums enumerated as extensions makes perfect sense to me, at least
until a H' standard (in whatever form) is actually released.

That said, this really have little bearing on the current discussion,
since as you say this particular case won't make it to H' anyway. I
don't really see any good arguments why MonoPatBinds shouldn't be the
listed extension.

Cheers,

/Niklas
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Isaac Dupree-3]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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
obviously be discouraged then. You could use OPTIONS_GHC pragmas with
-XNoMonoPatBinds instead though. Why is it annoying specifically?

Cheers,

/Niklas
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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 constructor has been deprecated in GHC and
>> superceded by ScopedTypeVariables.
>
> 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.

Cheers,

/Niklas
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts-4]

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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries