gmane.comp.lang.haskell.libraries

Don Stewart | 12 Oct 03:12

2008-10-11 Hackage status with GHC 6.10


Daily update of the state of Hackage wrt. GHC 6.10 release candidates.

Lots of packages were updated today, Cabal 1.6 and cabal-install 0.6
were also put out. Things are in a good shape.

Note that you'll need a "soft dep" in your cabal index file,

    base < 4
    parsec < 3
    HaXml == 1.13.*
    QuickCheck < 2

for best results.

Using GHC 6.10 RC, Cabal 1.6 and cabal-install 1.16, of 684 libraries
and apps tried in total,

      1 UnpackFailed
      2 DownloadFailed
      2 InstallFailed
     16 ConfigureFailed
     74 DependencyFailed
    134 BuildFailed
    455 InstallOk

Compared to GHC 6.8.x's results, there are now *48* packages that
produce different results, or *6%* (down 2% from yesterday).

The most common issues are,

(Continue reading)

Henning Thielemann | 12 Oct 15:40

Re: 2008-10-11 Hackage status with GHC 6.10

On Sat, 11 Oct 2008, Don Stewart wrote:

> Build reports for these packages were posted yesterday,
>
>    http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/15430

For 'numeric-prelude' it is reported:

numeric-prelude
     src/Number/Complex.hs:3:12:
         cannot parse LANGUAGE pragma: comma-separated list expected

The offending pragma is:
{-# LANGUAGE_HOW_CAN_WE_ENABLE Rules ? #-}

Why is this interpreted as LANGUAGE pragma at all?

... and erm, how can I enable parsing of optimizer rules?
With {-# OPTIONS_GHC -O #-} ?

Ian Lynagh | 12 Oct 15:56

Re: 2008-10-11 Hackage status with GHC 6.10

On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
> 
> ... and erm, how can I enable parsing of optimizer rules?
> With {-# OPTIONS_GHC -O #-} ?

Yes, although note that Cabal passes -O by default. I'd recommend not
putting it in a pragma, as that will break
    ./Setup configure --disable-optimization

Thanks
Ian

Duncan Coutts | 12 Oct 18:52

Re: 2008-10-11 Hackage status with GHC 6.10

On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
> On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
> > 
> > ... and erm, how can I enable parsing of optimizer rules?
> > With {-# OPTIONS_GHC -O #-} ?
> 
> Yes, although note that Cabal passes -O by default. I'd recommend not
> putting it in a pragma, as that will break
>     ./Setup configure --disable-optimization

I think the question was how to get the RULES pragmas to be parsed. One
does have to turn on a language extension to get the forall in rules to
parse and it's not very clear at the moment which one we should be
using.

See http://hackage.haskell.org/trac/ghc/ticket/2497

Duncan

Don Stewart | 12 Oct 20:09

Re: 2008-10-11 Hackage status with GHC 6.10

duncan.coutts:
> On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
> > On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
> > > 
> > > ... and erm, how can I enable parsing of optimizer rules?
> > > With {-# OPTIONS_GHC -O #-} ?
> > 
> > Yes, although note that Cabal passes -O by default. I'd recommend not
> > putting it in a pragma, as that will break
> >     ./Setup configure --disable-optimization
> 
> I think the question was how to get the RULES pragmas to be parsed. One
> does have to turn on a language extension to get the forall in rules to
> parse and it's not very clear at the moment which one we should be
> using.
> 
> See http://hackage.haskell.org/trac/ghc/ticket/2497

I've been suggesting Rank2Types, which does the trick.

-- Don

Henning Thielemann | 12 Oct 20:38

Re: 2008-10-11 Hackage status with GHC 6.10

On Sun, 12 Oct 2008, Duncan Coutts wrote:

> On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
>> On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
>>>
>>> ... and erm, how can I enable parsing of optimizer rules?
>>> With {-# OPTIONS_GHC -O #-} ?
>>
>> Yes, although note that Cabal passes -O by default. I'd recommend not
>> putting it in a pragma, as that will break
>>     ./Setup configure --disable-optimization
>
> I think the question was how to get the RULES pragmas to be parsed.

I wondered whether it is possible to let the compiler read and store the 
RULES pragmas without optimizing the code in the same module with respect 
to these RULES. When I want to compile the code without optimization - for 
whatever reason - I would still like to have the RULES checked. They could 
still be applied when imported to another module that is compiled with 
optimization.

Simon Peyton-Jones | 13 Oct 15:04

RE: 2008-10-11 Hackage status with GHC 6.10

| >> Yes, although note that Cabal passes -O by default. I'd recommend not
| >> putting it in a pragma, as that will break
| >>     ./Setup configure --disable-optimization
| >
| > I think the question was how to get the RULES pragmas to be parsed.

There's a bug I'm fixing (http://hackage.haskell.org/trac/ghc/ticket/2497).

| I wondered whether it is possible to let the compiler read and store the
| RULES pragmas without optimizing the code in the same module with respect
| to these RULES. When I want to compile the code without optimization - for
| whatever reason - I would still like to have the RULES checked. They could
| still be applied when imported to another module that is compiled with
| optimization.

Indeed you can: use -fno-omit-interface-pragmas. This overrides the default, which is that with -O no
non-essential info is put in the interface file.

If you think it's worth improving the documentation (e.g. you didn't know about this), then I'd welcome a
concrete suggestion.  (eg Say "...this..." in the second bullet off ...".)

Simon

Henning Thielemann | 15 Oct 20:47

RE: 2008-10-11 Hackage status with GHC 6.10


On Mon, 13 Oct 2008, Simon Peyton-Jones wrote:

> | I wondered whether it is possible to let the compiler read and store the
> | RULES pragmas without optimizing the code in the same module with respect
> | to these RULES. When I want to compile the code without optimization - for
> | whatever reason - I would still like to have the RULES checked. They could
> | still be applied when imported to another module that is compiled with
> | optimization.
>
> Indeed you can: use -fno-omit-interface-pragmas. This overrides the 
> default, which is that with -O no non-essential info is put in the 
> interface file.
>
> If you think it's worth improving the documentation (e.g. you didn't 
> know about this), then I'd welcome a concrete suggestion.  (eg Say 
> "...this..." in the second bullet off ...".)

  I found it just confusing to switch on two features (namely 'optimization 
including application of rules' and 'parsing, checking and storing new 
rules') with one option (namely -O). It remains confusing for me also if 
one of the two features can be enabled separately with 
-fno-omit-interface-pragmas, but the other feature cannot. Also the option 
sounds like it also applies not only to RULES. I also find the doubled 
negation in 'no omit' confusing. What about 
'-finclude-all-interface-pragmas'?
  What concerns documentation: The description of an option for enabling 
parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.

Duncan Coutts | 16 Oct 06:56

RE: 2008-10-11 Hackage status with GHC 6.10

On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:

>   I found it just confusing to switch on two features (namely 'optimization 
> including application of rules' and 'parsing, checking and storing new 
> rules') with one option (namely -O). It remains confusing for me also if 
> one of the two features can be enabled separately with 
> -fno-omit-interface-pragmas, but the other feature cannot. Also the option 
> sounds like it also applies not only to RULES. I also find the doubled 
> negation in 'no omit' confusing. What about 
> '-finclude-all-interface-pragmas'?
>   What concerns documentation: The description of an option for enabling 
> parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.

While it used to be more complex, the situation now is quite simple:

RULES are always parsed (no flags or language extensions needed). They
also go into the .hi files (unless you use the obscure option to change
that), so they are exported for all client modules.

RULES get used/applied with -O. Again, there is an option to turn off
the use of rules (without affecting other optimisations).

This seems pretty sane and easy to explain.

Duncan

Simon Peyton-Jones | 16 Oct 12:12

RE: 2008-10-11 Hackage status with GHC 6.10

| RULES are always parsed (no flags or language extensions needed). They
| also go into the .hi files (unless you use the obscure option to change
| that), so they are exported for all client modules.

The latter isn't true, and I think that's what Henning is objecting to.

Currently, without -O GHC puts the absolute minimum in interface files to get the clients to compile: just
the exports and their types.  For example, if you have
        f x = x
GHC will not put that unfolding in the interface file, tiny though it is.

Currently without -O GHC therefore does *not* put RULES in the interface file.  I thought that was
consistent, since they are to do with optimisation.

If, however, there's a consensus that RULES should be persisted even without -O, that'd be easy to arrange.
For example, I think that deprecations are persisted unconditionally.

Simon

| -----Original Message-----
| From: Duncan Coutts [mailto:duncan.coutts <at> worc.ox.ac.uk]
| Sent: 16 October 2008 05:57
| To: Henning Thielemann
| Cc: Simon Peyton-Jones; libraries <at> haskell.org
| Subject: RE: 2008-10-11 Hackage status with GHC 6.10
|
| On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:
|
| >   I found it just confusing to switch on two features (namely 'optimization
| > including application of rules' and 'parsing, checking and storing new

(Continue reading)

Don Stewart | 16 Oct 20:40

Re: 2008-10-11 Hackage status with GHC 6.10

simonpj:
> | RULES are always parsed (no flags or language extensions needed). They
> | also go into the .hi files (unless you use the obscure option to change
> | that), so they are exported for all client modules.
> 
> The latter isn't true, and I think that's what Henning is objecting to.
> 
> Currently, without -O GHC puts the absolute minimum in interface files
> to get the clients to compile: just the exports and their types.  For
> example, if you have
>         f x = x
> GHC will not put that unfolding in the interface file, tiny though it
> is.
> 
> Currently without -O GHC therefore does *not* put RULES in the
> interface file.  I thought that was consistent, since they are to do
> with optimisation.
> 
> If, however, there's a consensus that RULES should be persisted even
> without -O, that'd be easy to arrange. For example, I think that
> deprecations are persisted unconditionally.

So the next build with GHC 6.10 branch we should no longer see
'forall' parse failures from hackage libraries that use RULES?

-- Don

Simon Peyton-Jones | 17 Oct 09:29

RE: 2008-10-11 Hackage status with GHC 6.10

| So the next build with GHC 6.10 branch we should no longer see
| 'forall' parse failures from hackage libraries that use RULES?

Yes -- but not for the reasons below.  It should work now because I fixed http://hackage.haskell.org/trac/ghc/ticket/2497

Simon

| -----Original Message-----
| From: Don Stewart [mailto:dons <at> galois.com]
| Sent: 16 October 2008 19:40
| To: Simon Peyton-Jones
| Cc: Duncan Coutts; Henning Thielemann; libraries <at> haskell.org
| Subject: Re: 2008-10-11 Hackage status with GHC 6.10
|
| simonpj:
| > | RULES are always parsed (no flags or language extensions needed). They
| > | also go into the .hi files (unless you use the obscure option to change
| > | that), so they are exported for all client modules.
| >
| > The latter isn't true, and I think that's what Henning is objecting to.
| >
| > Currently, without -O GHC puts the absolute minimum in interface files
| > to get the clients to compile: just the exports and their types.  For
| > example, if you have
| >         f x = x
| > GHC will not put that unfolding in the interface file, tiny though it
| > is.
| >
| > Currently without -O GHC therefore does *not* put RULES in the
| > interface file.  I thought that was consistent, since they are to do

(Continue reading)

Duncan Coutts | 16 Oct 20:47

RE: 2008-10-11 Hackage status with GHC 6.10

On Thu, 2008-10-16 at 11:12 +0100, Simon Peyton-Jones wrote:
> | RULES are always parsed (no flags or language extensions needed). They
> | also go into the .hi files (unless you use the obscure option to change
> | that), so they are exported for all client modules.
> 
> The latter isn't true, and I think that's what Henning is objecting
> to.

Oops.

As I read it Henning wants the RULES parsed with or without -O. That bit
is now much simpler than it used to be.

I didn't read his objection as wanting them always exported even if the
defining module was not built without -O, just that they should always
be parsed and checked.

> Currently, without -O GHC puts the absolute minimum in interface files
> to get the clients to compile

Right. My mistake.

> Currently without -O GHC therefore does *not* put RULES in the
> interface file.  I thought that was consistent, since they are to do
> with optimisation.

Right. 

> If, however, there's a consensus that RULES should be persisted even
> without -O, that'd be easy to arrange. For example, I think that

(Continue reading)

Henning Thielemann | 16 Oct 16:58

RE: 2008-10-11 Hackage status with GHC 6.10


On Wed, 15 Oct 2008, Duncan Coutts wrote:

> On Wed, 2008-10-15 at 20:47 +0200, Henning Thielemann wrote:
>
>>   I found it just confusing to switch on two features (namely 'optimization
>> including application of rules' and 'parsing, checking and storing new
>> rules') with one option (namely -O). It remains confusing for me also if
>> one of the two features can be enabled separately with
>> -fno-omit-interface-pragmas, but the other feature cannot. Also the option
>> sounds like it also applies not only to RULES. I also find the doubled
>> negation in 'no omit' confusing. What about
>> '-finclude-all-interface-pragmas'?
>>   What concerns documentation: The description of an option for enabling
>> parsing of RULES I would expect in ghc-doc/users_guide/rewrite-rules.html.
>
> While it used to be more complex, the situation now is quite simple:
>
> RULES are always parsed (no flags or language extensions needed). They
> also go into the .hi files (unless you use the obscure option to change
> that), so they are exported for all client modules.

So they are handled like all pragmas. That sounds fine to me.

> RULES get used/applied with -O. Again, there is an option to turn off
> the use of rules (without affecting other optimisations).
>
> This seems pretty sane and easy to explain.

yes, indeed

(Continue reading)

Simon Peyton-Jones | 15 Oct 10:46

RE: 2008-10-11 Hackage status with GHC 6.10

Right.  I've finally fixed 2497; it was a typo, and while I thought I'd tested it, the test didn't tet that
RULES compile without any flags.

The story is that you should not need any funny RankN flags just to make RULES parse and typecheck.
-XScopedTypeVariables gets set automatically inside a RULES pragma.  This is what the discussion on
#2497 claimed, but there was a bug in the impl.

Ian pls merge:

Simon

| -----Original Message-----
| From: libraries-bounces <at> haskell.org [mailto:libraries-bounces <at> haskell.org] On Behalf Of Duncan
| Coutts
| Sent: 12 October 2008 17:53
| To: Ian Lynagh
| Cc: Henning Thielemann; libraries <at> haskell.org
| Subject: Re: 2008-10-11 Hackage status with GHC 6.10
|
| On Sun, 2008-10-12 at 14:56 +0100, Ian Lynagh wrote:
| > On Sun, Oct 12, 2008 at 03:40:53PM +0200, Henning Thielemann wrote:
| > >
| > > ... and erm, how can I enable parsing of optimizer rules?
| > > With {-# OPTIONS_GHC -O #-} ?
| >
| > Yes, although note that Cabal passes -O by default. I'd recommend not
| > putting it in a pragma, as that will break
| >     ./Setup configure --disable-optimization
|
| I think the question was how to get the RULES pragmas to be parsed. One

(Continue reading)

Duncan Coutts | 15 Oct 19:58

RE: 2008-10-11 Hackage status with GHC 6.10

On Wed, 2008-10-15 at 09:46 +0100, Simon Peyton-Jones wrote:
> Right.  I've finally fixed 2497; it was a typo, and while I thought
> I'd tested it, the test didn't tet that RULES compile without any
> flags.

That's great, thanks.

> The story is that you should not need any funny RankN flags just to
> make RULES parse and typecheck. -XScopedTypeVariables gets set
> automatically inside a RULES pragma.  This is what the discussion on
> #2497 claimed, but there was a bug in the impl.

And for people trying to make their code compatible with older ghc too,
they can use this in their .cabal files:

extensions: ScopedTypeVariables

Which makes Cabal pass -XScopedTypeVariables for ghc-6.8 and for 6.6 and
earlier is passes -fglasgow-exts. This is what the bytestring package is
currently using (and no more ghc-options: -fglasgow-exts).

Duncan

Return

Return to gmane.comp.lang.haskell.libraries.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane