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

[Austin Seipp]

On Mon, Aug 4, 2014 at 8:49 AM, Geoffrey Mainland <mainland at apeiron.net> wrote:
> I have patches for DPH that let it work with vector 0.11 as of a few
> months ago. I would be happy to submit them via phabricator if that is
> agreeable (we have to coordinate with the import of vector 0.11
> though...I can instead leave them in a wip branch for Austin to merge as
> he sees fit). I am also willing to commit some time to keep DPH at least
> working in its current state.

That would be quite nice if you could submit patches to get it to
work! Thanks so much.

As we've moved to submodules, having our own forks is becoming less
palatable; we'd like to start tracking upstream closely, and having
people submit changes there first and foremost. This creates a bit of
a lag time between changes, but I think this is acceptable (and most
of our maintainers are quite responsive to GHC needs!)

It's also great you're willing to help maintain DPH a bit - but based
on what Ben said, it seems like a significant rewrite will happen
eventually.

Geoff, here's my proposal:

 1) I'll disable DPH for right now, so it won't pop up during
./validate. This will probably happen today.
 2) We can coordinate the update of vector to 0.11, making it track
the official master. (Perhaps an email thread or even Skype would
work)
 3) We can fix DPH at the same time.
 4) Afterwords, we can re-enable it for ./validate

If you submit Phabricator patches, that would be fantastic - we can
add the DPH repository to Phabricator with little issue.

In the long run, I think we should sync up with Ben and perhaps Simon
& Co to see what will happen long-term for the DPH libraries.

> Geoff
>
> On 8/4/14 8:18 AM, Ben Lippmeier 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.
>>
>>
>>> [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.
>>
>> 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.
>>
>> Sorry for the trouble.
>> Ben.
>>
>



-- 
Regards,

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