Re: Why are there no Show instances for internal types

2017-03-18 Thread Ben Gamari 
Tom Sydney Kerckhove  writes:

> On 19-03-17 02:08:56, Rahul Muttineni wrote:
>> Syd, can you tell us what kind of things you were trying to print out?
>
> Maybe I wasn't very clear.
> I'm trying to visualise the internal structure of some of the
> typechecker's output.
> I specifically do NOT need to see the output of Outputable's functions.
> They show the human-readibly version and not the internal structure.
>
Indeed I am sympathetic to this request. In my time working on GHC I
have written raw several variants of `Type -> SDoc`, each exposing
various levels of detail. These are handy and can be a good way to gain
insight into the AST, but I feel like it is hard to come up with
something that is generally applicable; I find each time I need to
expose slightly different details about the internal structure of the
representation.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Stat too good

2017-03-18 Thread Ben Gamari 
Simon Peyton Jones via ghc-devs  writes:

> Ben,
> I still get these four stat-too-good "failures" on 64-bit Linux.
>
> Unexpected stat failures:
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T13035.run  T13035 [stat 
> too good] (normal)
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T12425.run  T12425 [stat 
> too good] (optasm)
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T1969.run   T1969 [stat 
> too good] (normal)
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T9233.run   T9233
>[stat too good] (normal)
>
> Don't you?

I'm not seeing anything like this at the moment but I have seen a great
deal of variability in testsuite results recently. In fact, I had to bump the
acceptance window size of T4029 as my local machine, Harbormaster, and
the OS X build bot differed by nearly 10% in max_bytes_used.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Tom Sydney Kerckhove 
On 18-03-17 16:13:52, Ben Gamari wrote:
> 
> 
> On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove 
>  wrote:
> 
> Snip.
> >
> >My questions for you:
> >
> >- Is there a reason that there are no derived 'Show' instances for most
> >  types?
> 
> As Richard mentioned, we don't derive Show due to code size and compilation 
> time concerns.

Okay.

> Show in particular is rather expensive to derive and seeing as we already 
> have Outputable I don't it would make sense to derive it by default.

Show and Outputable have very different goals though.

> I would really like to avoid introducing more CPP into the code base for this 
> particular problem.

Fair enough.

> One alternative which will work in many cases is to simply derive Show 
> yourself using StandaloneDeriving. Does this help?

That doesn't work if some type doesn't have the constructors exposed.
I tried this already, and it would be a good solution if all
constructors were exposed, ...

> Cheers,
> 
> - Ben 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Tom Sydney Kerckhove


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Tom Sydney Kerckhove 
On 19-03-17 02:08:56, Rahul Muttineni wrote:
> Syd, can you tell us what kind of things you were trying to print out?

Maybe I wasn't very clear.
I'm trying to visualise the internal structure of some of the
typechecker's output.
I specifically do NOT need to see the output of Outputable's functions.
They show the human-readibly version and not the internal structure.

Does that answer your question?
> Hope that helps,
> Rahul
> 
> On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang  wrote:
> 
> > We can't add Show instances for these types because many types
> > below them, e.g., Type, are cyclic, and would result in infinite
> > output.
> >
> > Perhaps we can add a new type class which a) faithfully represents
> > the Haskell syntax, but b) can deal with cyclic data.  I think that's
> > something people would like (extra compilation time not withstanding).
> > But it sounds annoying to do since the deriving mechanism is not going
> > to help you.
> >
> > Edward
> >
> > Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > > Dear GHC Devs,
> > >
> > > I am trying to use GHC as a library but I'm having a lot of trouble with
> > > understanding what everything means.
> > > Up to now, I have been able to figure out what to do by reading the
> > > sources, but it ocured to me that much of my struggles could have been
> > > mitigated if the relevant types had Show instances.
> > >
> > > I am specifically talking about the types concerning type checking.
> > > TypecheckedModule and everything below that.
> > > I am aware that most of the types have an Outputable instance, but
> > > there are two problems with that:
> > >
> > > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > > - These instances are not intended to show the internal structure of a
> > >   value, but rather a 'human readable' representation of a value.
> > >
> > > My questions for you:
> > >
> > > - Is there a reason that there are no derived 'Show' instances for most
> > >   types?
> > > - Would you accept a diff that adds these?
> > >
> > > Thank you for your time.
> > >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> 
> 
> 
> -- 
> Rahul Muttineni

-- 
Tom Sydney Kerckhove


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Compiling CMM tests with LLVM

2017-03-18 Thread Erik de Castro Lopo 
Erik de Castro Lopo wrote:

> Hi all,
> 
> I'm working on a minor change to CMM (#13442) and while writing the
> tests realized that the CMM tests were only run with `-fasm` and not
> with `-fllvm`. Furthermore other than running the test manually myself,
> I could not figure out how to make it compile with LLVM.
> 
> My test (in my WIP local branch) is:
> 
> testsuite/tests/codeGen/should_compile/T13442.cmm
> 
> and I updated the `all.T` in that same directory with the line:
> 
> test('T13442', [cmm_src], compile, ['-dcmm-lint'])
> 
> Anyone have any clues as to how to make this compile with LLVM if
> LLVM is available? I suspect it should probably be turned on for
> the vast majority of the CMM tests.

Ok, I added the following function to `testlib.py`:

def cmm_src_llvm( name, opts ):
opts.only_ways = ['optllvm', 'llvm', 'debugllvm']
opts.cmm_src = 1;

and changed my test set up to:

 test('T13442', [cmm_src, cmm_src_llvm], compile, ['-dcmm-lint'])

Would still be interested to know if this is the correct way and
if there is a better way.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Compiling CMM tests with LLVM

2017-03-18 Thread Erik de Castro Lopo 
Hi all,

I'm working on a minor change to CMM (#13442) and while writing the
tests realized that the CMM tests were only run with `-fasm` and not
with `-fllvm`. Furthermore other than running the test manually myself,
I could not figure out how to make it compile with LLVM.

My test (in my WIP local branch) is:

testsuite/tests/codeGen/should_compile/T13442.cmm

and I updated the `all.T` in that same directory with the line:

test('T13442', [cmm_src], compile, ['-dcmm-lint'])

Anyone have any clues as to how to make this compile with LLVM if
LLVM is available? I suspect it should probably be turned on for
the vast majority of the CMM tests.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Ben Gamari 
Rahul Muttineni  writes:

> I think another way to go about this problem is to figure out an
> alternative to baking in DynFlags to SDocContext (which I feel is the core
> problem here). The only use of those DynFlags is via sdocWithDynFlags and
> 94 call sites use them.
>
Indeed, I would love to see this happen. This exact request is being
tracked as #10143.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Joachim Breitner 
Am Samstag, den 18.03.2017, 14:03 +0100 schrieb Tom Sydney Kerckhove:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)


You can often get away with

showSDocUnsafe . ppr :: Outputable a => a -> String

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Rahul Muttineni 
I think another way to go about this problem is to figure out an
alternative to baking in DynFlags to SDocContext (which I feel is the core
problem here). The only use of those DynFlags is via sdocWithDynFlags and
94 call sites use them.

- In the frontend, it's used to check for the presence of the flag (like
suppress module prefixes, etc.)
- In the code generator, it's used to get the word size, endianness, and
other platform specific stuff for platform-specific printing.
- Backpack-related stuff needed to get the package state
  - Used in exactly 2 cases: Outputable instances for ComponentId and
InstalledUnitId

>From what I observed with the majority of use cases, sdocWithDynFlags is
used to obviate the need for passing dflags to various ppr* functions,
which is a good idea since without it, we'd probably have to pass around
DynFlags to a whole lot more pure functions throughout the codebase.

So as others have said, Show instances are just not practical because
printing many of the GHC types is highly dependent on the platform and what
flags GHC was invoked with.

There are three solutions here:
1.) Figure out a subset of DynFlags (flags, platform details, package
state) and only allow those inside of SDocContext and extend SDocContext as
 new use cases come up. This is probably not practical as it would
require sweeping changes.
2.) Provide a stock set of DynFlags for the purpose of printing with
Outputable. It's easy to do for flags and platform details, but tricky to
do for package state. This seems to be the most reasonable solution if some
sane substitute for package state can be used.

Syd, can you tell us what kind of things you were trying to print out? You
can try to pass in unsafeGlobalDynFlags but it may not be what you want. It
gets written to on the initialisation of the GHC monad and after the
command line options are parsed (so everything will be properly initialised
except for package state).

Hope that helps,
Rahul

On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang  wrote:

> We can't add Show instances for these types because many types
> below them, e.g., Type, are cyclic, and would result in infinite
> output.
>
> Perhaps we can add a new type class which a) faithfully represents
> the Haskell syntax, but b) can deal with cyclic data.  I think that's
> something people would like (extra compilation time not withstanding).
> But it sounds annoying to do since the deriving mechanism is not going
> to help you.
>
> Edward
>
> Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > Dear GHC Devs,
> >
> > I am trying to use GHC as a library but I'm having a lot of trouble with
> > understanding what everything means.
> > Up to now, I have been able to figure out what to do by reading the
> > sources, but it ocured to me that much of my struggles could have been
> > mitigated if the relevant types had Show instances.
> >
> > I am specifically talking about the types concerning type checking.
> > TypecheckedModule and everything below that.
> > I am aware that most of the types have an Outputable instance, but
> > there are two problems with that:
> >
> > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > - These instances are not intended to show the internal structure of a
> >   value, but rather a 'human readable' representation of a value.
> >
> > My questions for you:
> >
> > - Is there a reason that there are no derived 'Show' instances for most
> >   types?
> > - Would you accept a diff that adds these?
> >
> > Thank you for your time.
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Rahul Muttineni
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Ben Gamari 


On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove 
 wrote:

Snip.
>
>My questions for you:
>
>- Is there a reason that there are no derived 'Show' instances for most
>  types?

As Richard mentioned, we don't derive Show due to code size and compilation 
time concerns. Show in particular is rather expensive to derive and seeing as 
we already have Outputable I don't it would make sense to derive it by default. 
I would really like to avoid introducing more CPP into the code base for this 
particular problem.

One alternative which will work in many cases is to simply derive Show yourself 
using StandaloneDeriving. Does this help?

Cheers,

- Ben 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Alan & Kim Zimmerman 
And I guess it would be bad to use Show, but make custom instances for the
problematic types that did not loop?

Alan

On 18 Mar 2017 9:44 pm, "Edward Z. Yang"  wrote:

> We can't add Show instances for these types because many types
> below them, e.g., Type, are cyclic, and would result in infinite
> output.
>
> Perhaps we can add a new type class which a) faithfully represents
> the Haskell syntax, but b) can deal with cyclic data.  I think that's
> something people would like (extra compilation time not withstanding).
> But it sounds annoying to do since the deriving mechanism is not going
> to help you.
>
> Edward
>
> Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > Dear GHC Devs,
> >
> > I am trying to use GHC as a library but I'm having a lot of trouble with
> > understanding what everything means.
> > Up to now, I have been able to figure out what to do by reading the
> > sources, but it ocured to me that much of my struggles could have been
> > mitigated if the relevant types had Show instances.
> >
> > I am specifically talking about the types concerning type checking.
> > TypecheckedModule and everything below that.
> > I am aware that most of the types have an Outputable instance, but
> > there are two problems with that:
> >
> > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > - These instances are not intended to show the internal structure of a
> >   value, but rather a 'human readable' representation of a value.
> >
> > My questions for you:
> >
> > - Is there a reason that there are no derived 'Show' instances for most
> >   types?
> > - Would you accept a diff that adds these?
> >
> > Thank you for your time.
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Edward Z. Yang 
We can't add Show instances for these types because many types
below them, e.g., Type, are cyclic, and would result in infinite
output.

Perhaps we can add a new type class which a) faithfully represents
the Haskell syntax, but b) can deal with cyclic data.  I think that's
something people would like (extra compilation time not withstanding).
But it sounds annoying to do since the deriving mechanism is not going
to help you.

Edward

Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> Dear GHC Devs,
> 
> I am trying to use GHC as a library but I'm having a lot of trouble with
> understanding what everything means.
> Up to now, I have been able to figure out what to do by reading the
> sources, but it ocured to me that much of my struggles could have been
> mitigated if the relevant types had Show instances.
> 
> I am specifically talking about the types concerning type checking.
> TypecheckedModule and everything below that.
> I am aware that most of the types have an Outputable instance, but
> there are two problems with that:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> - These instances are not intended to show the internal structure of a
>   value, but rather a 'human readable' representation of a value.
> 
> My questions for you:
> 
> - Is there a reason that there are no derived 'Show' instances for most
>   types?
> - Would you accept a diff that adds these?
> 
> Thank you for your time.
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Stat too good

2017-03-18 Thread Michal Terepeta 
Just FYI: I'm on 64-bit Linux and don't see those failures (I just
validated at 763f43e6d3)

Cheers,
Michal

On Fri, Mar 17, 2017 at 6:49 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Ben,
>
> I still get these four stat-too-good “failures” on 64-bit Linux.
>
> Unexpected stat failures:
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T13035.run  T13035
> [stat too good] (normal)
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T12425.run  T12425
> [stat too good] (optasm)
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T1969.run   T1969
> [stat too good] (normal)
>
>/tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T9233.run   T9233
> [stat too good] (normal)
>
> Don’t you?
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: PSA: perf.haskell.org/ghc temporarily out of order

2017-03-18 Thread Joachim Breitner 
Hi,

correct. It seems that 'make boot' tries to compile all of nofib, even
those that are not to be run. So this ought to be revised.

Greetings,
Joachim

Am Samstag, den 18.03.2017, 01:56 -0400 schrieb Reid Barton:
> Don't know whether it is the same issue, but perf.haskell.org seems
> to
> still have not built anything for the past 3 days, according to
> https://github.com/nomeata/ghc-speed-logs/commits/master.
> 
> Regards,
> Reid Barton
> 
> On Wed, Mar 15, 2017 at 5:49 PM, Ben Gamari 
> wrote:
> > Joachim Breitner  writes:
> > 
> > > Hi,
> > > 
> > > a recent change to nofib
> > > (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e
> > > 8ac26d4dfe3c0a)
> > > broke the perf.haskell.org builder, so we won’t be getting perf
> > > warnings until that is fixed.
> > > 
> > 
> > I've pushed the michalt's fix. Thanks for the quick turnaround,
> > michalt!
> > 
> > Cheers,
> > 
> > - Ben
> > 
> > 
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > 
> 
> 
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Travis again over time

2017-03-18 Thread Eric Seidel 
On Sat, Mar 18, 2017, at 05:36, Alan & Kim Zimmerman wrote:
> FYI, liquidhaskell switched from travis to circleci.com because of
> timeout
> problems.
> 
> It seems the time available is larger there.

IIRC CircleCI doesn't have an overall build timeout at all, just
(configurable) per-command timeouts.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

2017-03-18 Thread Richard Eisenberg 
My take is that we don't have these because they would slow down compilation 
times and add bloat. But enough people have asked for them (and, I can think of 
a few times when I would use them myself) that I think they should be added.

It is conceivable that we could make the instances only when DEBUG is on. That 
would, I believe, involve some unsavory CPP, and may not be worth it. What do 
others think?

Richard

> On Mar 18, 2017, at 9:03 AM, Tom Sydney Kerckhove  
> wrote:
> 
> Dear GHC Devs,
> 
> I am trying to use GHC as a library but I'm having a lot of trouble with
> understanding what everything means.
> Up to now, I have been able to figure out what to do by reading the
> sources, but it ocured to me that much of my struggles could have been
> mitigated if the relevant types had Show instances.
> 
> I am specifically talking about the types concerning type checking.
> TypecheckedModule and everything below that.
> I am aware that most of the types have an Outputable instance, but
> there are two problems with that:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> - These instances are not intended to show the internal structure of a
>  value, but rather a 'human readable' representation of a value.
> 
> My questions for you:
> 
> - Is there a reason that there are no derived 'Show' instances for most
>  types?
> - Would you accept a diff that adds these?
> 
> Thank you for your time.
> 
> -- 
> Tom Sydney Kerckhove
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Why are there no Show instances for internal types

2017-03-18 Thread Tom Sydney Kerckhove 
Dear GHC Devs,

I am trying to use GHC as a library but I'm having a lot of trouble with
understanding what everything means.
Up to now, I have been able to figure out what to do by reading the
sources, but it ocured to me that much of my struggles could have been
mitigated if the relevant types had Show instances.

I am specifically talking about the types concerning type checking.
TypecheckedModule and everything below that.
I am aware that most of the types have an Outputable instance, but
there are two problems with that:

- 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
- These instances are not intended to show the internal structure of a
  value, but rather a 'human readable' representation of a value.

My questions for you:

- Is there a reason that there are no derived 'Show' instances for most
  types?
- Would you accept a diff that adds these?

Thank you for your time.

-- 
Tom Sydney Kerckhove


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Travis again over time

2017-03-18 Thread Alan & Kim Zimmerman 
FYI, liquidhaskell switched from travis to circleci.com because of timeout
problems.

It seems the time available is larger there.

And you get access to the build artifacts afterward, as per your
configuration.

Alan

On 9 March 2017 at 19:17, Joachim Breitner  wrote:

> Hi,
>
> Am Dienstag, den 07.03.2017, 14:39 +0100 schrieb Joachim Breitner:
> > The build would be marked as passing if it were not for
> > integerConstantFolding which is marked as …
>
> fixed this issue. Travis should pass now again. Let’s keep it this way!
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs