The proposed changes look fine to me. A couple of thoughts: 1. This adds a new constraint on the dataflow algorithm, namely that it must traverse the blocks in the correct order. I think that's a *good* thing, because we definitely want to traverse blocks in the right order for performance reasons, and now if we get it wrong the algorithm will crash. I got the order wrong more than once while working on hoopl, and the only consequence was that things were slower than necessary. 2. Has anyone tried implementing this change? I'm slightly concerned that having a difference between forward and backward analyses might lead to divergence in some of the shared parts of the internals of the algorithm. But maybe it will work out ok. Do please measure performance carefully though. Cheers, Simon On 22/08/13 17:44, Simon Peyton-Jones wrote:
I have elaborated (more clearly I hope)
S
| -----Original Message----- | From: Simon Marlow [mailto:marlowsd@gmail.com] | Sent: 22 August 2013 15:14 | To: Jan Stolarek | Cc: ghc-devs; Simon Peyton-Jones; nr@cs.tufts.edu; dias@cs.tufts.edu; | Edward Z. Yang | Subject: Re: Changes in Hoopl | | Hi Jan, | | On 22/08/13 14:01, Jan Stolarek wrote: | > Me and Simon PJ had some discussion about modifying Hoopl. I | summarized that discussion on a wiki page: | > | > http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup | > | > I'd like to implement changes once there's a consensus on which | changes exactly do we want in Hoopl. | | I'm all for cleaning up Hoopl. It's definitely a bit of a mess in | places. | | I read through your wiki page and I'm not entirely clear about what | changes you're proposing. e.g. it's probably true that in forward | analysis if you specify facts for all the input labels then fact_bot is | never used (though I'm not 100% sure about that). But you don't say | what you want to do with that observation. Could you list the API | changes you want to make? | | Cheers, | Simon