I’ve had a chat to Manuel.  He is content for us to remove DPH code altogether 
(not just CPP/comment it out), provided we are careful to signpost what has 
gone and how to get it back.

I am no Git expert, so can I leave it to you guys to work out what to do?  The 
specification is:

·        It should be clear how to revert the change; that is, to re-introduce 
the deleted code.  I guess that might be “git revert <some horrible hash>”

·        If someone trips over more DPH code later, and wants to remove that 
too, it should be clear how to add it to the list of things to be revertred.

·        We should have a Trac ticket “Resume work on DPH and vectorisation” or 
something like that, which summarises the reversion process.

Just to be clear, this does not indicate any lack of interest in DPH on my 
part.  (Quite the reverse.)   It’s just that while no one is actually working 
on it, we should use our source code control system to move it out of the way, 
as others on this thread have persuasively argued.

Manuel, yell if I got anything wrong.

Thanks!

Simon





From: ghc-devs [mailto:[email protected]] On Behalf Of Carter 
Schonwald
Sent: 21 January 2015 03:32
To: RodLogic
Cc: Manuel M T Chakravarty; [email protected]
Subject: Re: vectorisation code?

moving it to its own submodule is just a complicated version of cutting a 
branch that has the code Right before deleting it from master.
afaik, the amount of love needed is roughly "one or more full time grad 
students really owning it", though i could be wrong.


On Tue, Jan 20, 2015 at 5:39 AM, RodLogic 
<[email protected]<mailto:[email protected]>> wrote:
(disclaimer: I know nothing about the vectorization code)

Now, is the vectorization code really dead code or it is code that needs love 
to come back to life? By removing it from the code base, you are probably 
sealing it's fate as dead code as we are limiting new or existing contributors 
to act on it (even if it's a commit hash away). If it is code that needs love 
to come back to life, grep noise or conditional compilation is a small price to 
pay here, imho.

As a compromise, is it possible to move vectorization code into it's own 
submodule in git or is it too intertwined with core GHC? So that it can be 
worked on independent of GHC?


On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel 
<[email protected]<mailto:[email protected]>> wrote:
On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
>> Here's an alternate suggestion: in SimplCore, keep the call to vectorise
>> around, but commented out

> Yuck. Carter and Brandon are right here - we have git, let it do the
> job. I propose that we remove vectorization code, create a Trac ticket
> about vectorization & DPH needing love and record the commit hash in
> the ticket so that we can revert it easily in the future.

I'm also against commenting out dead code in the presence of a VCS.

Btw, here's two links discussing the issues related to commenting out if
anyone's interested in knowing more:

 - 
http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation

 - 
http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad


Cheers,
  hvr
_______________________________________________
ghc-devs mailing list
[email protected]<mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[email protected]<mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to