I'm going to disable DPH until someone starts maintaining it

Austin Seipp austin at well-typed.com
Mon Aug 4 14:03:21 UTC 2014

On Mon, Aug 4, 2014 at 7:18 AM, Ben Lippmeier <benl at ouroborus.net> wrote:
> On 4 Aug 2014, at 21:47 , Austin Seipp <austin at well-typed.com> wrote:
>> Why? Because I'm afraid I just don't have any more patience for DPH,
>> I'm tired of fixing it, and it takes up a lot of extra time to build,
>> and time to maintain.
> I'm not going to argue against cutting it lose.
>> So - why are we still building it, exactly?
> It can be a good stress test for the simplifier, especially the SpecConstr transform. The fact that it takes so long to build is part of the reason it's a good stress test.

That's definitely fair. There's also the problem that SpecConstr has
seen regressions lately causing explosions in the amount of time
needed to compile, which might be making this more problematic (I
can't remember the ticket # off hand).

>> [1] And by 'speak up', I mean I'd like to see someone actively step
>> forward address my concerns above in a decisive manner. With patches.
> I thought that in the original conversation we agreed that if the DPH code became too much of a burden it was fine to switch it off and let it become unmaintained. I don't have time to maintain it anymore myself.

Oh, I misremembered. It seems we're on the same page then :)

> The original DPH project has fractured into a few different research streams, none of which work directly with the implementation in GHC, or with the DPH libraries that are bundled with the GHC build.
> The short of it is that the array fusion mechanism implemented in DPH (based on stream fusion) is inadequate for the task. A few people are working on replacement fusion systems that aim to solve this problem, but merging this work back into DPH will entail an almost complete rewrite of the backend libraries. If it the existing code has become a maintenance burden then it's fine to switch it off.

I see, thanks. Is there any current roadmap on what might be done?

> Sorry for the trouble.
> Ben.

No problem. I suppose after dealing with the frustration of tracking a
single bug for a few days, this is just an annoyance that tipped me.


Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

More information about the ghc-devs mailing list