<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.m5429673471515783493msolistparagraph, li.m5429673471515783493msolistparagraph, div.m5429673471515783493msolistparagraph
{mso-style-name:m_5429673471515783493msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Michael<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Sorry to be slow.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">Note that what I’m actually advocating is to *finish* forking Hoopl. The<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">fork really started in ~2012 when the “new Cmm backend” was being<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">finished.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Yes, I know. But what I’m suggesting is to revisit the reasons for that fork, and re-join if possible. Eg if Hoopl is too slow, can’t we make it faster? Why is GHC’s version faster?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">apart from the performance<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">(as noted above), there’s the issue of Hoopl’s interface. IMHO the<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">node-oriented approach taken by Hoopl is both not flexible enough and it<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">makes it harder to optimize it. That’s why I’ve already changed GHC’s<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">`Hoopl.Dataflow` module to operate “block-at-a-time”<o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Well that sounds like an argument to re-engineer Hoopl’s API, rather an argument to fork it. If it’s a better API, can’t we make it better for everyone? I don’t yet understand what the “block-oriented”
API is, or how it differs, but let’s have the conversation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">When you say<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">that we should “just fix Hoopl”, it sounds to me that we’d really need<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">to rewrite it from scratch. And it’s much easier to do that if we can<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">just experiment within GHC without worrying about breaking other<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">existing Hoopl users<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Fine. But then let’s call it hoopl2, make it a separate package (perhaps with GHC as its only client for now), and declare that it’s intended to supersede hoopl.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">But do we even need to do that much? After all, a major version bump on a package is allowed to introduce breaking changes to the API. Anyone who wants the old API can use the old package.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">I wonder if you could start a wiki page somewhere (eg on the GHC wiki) listing all the changes you’d like to make in a “rewrite from scratch” story? That would help to “ground” the conversation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Michal Terepeta [mailto:michal.terepeta@gmail.com]
<br>
<b>Sent:</b> 29 May 2017 12:53<br>
<b>To:</b> Simon Peyton Jones <simonpj@microsoft.com>; ghc-devs <ghc-devs@haskell.org><br>
<b>Subject:</b> Re: Removing Hoopl dependency?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Sun, May 28, 2017 at 11:30 PM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Is there really a compelling case for forking Hoopl? I was talking to Kavon last week about doing exactly the opposite:
using Hoopl more wholeheartedly!</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Before going ahead with this, let’s remember the downsides</span><o:p></o:p></p>
<p class="m5429673471515783493msolistparagraph"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If we fork Hoopl, improvements in one place will not be seen in the other. GHC originally used its own containers library but now uses ‘containers’, most of which is irrelevant to GHC,
just to pick up the work that has been done to make ‘containers’ fast. Similarly, GHC has a clone of ‘pretty’, but someone is working (I think) to make GHC use ‘pretty’.</span><o:p></o:p></p>
<p class="m5429673471515783493msolistparagraph"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It’s not clear to me why GHC has a clone of parts of Hoopl. Would it not be better just to make Hoopl faster?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If anything I ‘d like to use Hoopl more in Cmm optimisation passes in GHC, so we may want to use more of Hoopl’s
facilities.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The main reason you suggest for forking is that there are some awkward name clashes. Surely we could resolve these?
e.g we could change CLabel in GHC; or agree with Hoopl maintainers that BlockId would be more helpful than Label.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">You mention that Hoopl uses Unique set/map. Why not use ‘containers’ for that? (Like GHC!)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Let’s discuss this a bit more before executing</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I’m also interested to know:</span><o:p></o:p></p>
<p class="m5429673471515783493msolistparagraph"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">who is actively working on Hoopl (Michael, Sophie, …)?</span><o:p></o:p></p>
<p class="m5429673471515783493msolistparagraph"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">how are you using it (within GHC, or somewhere else)?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">It’d be good to review and update
<a href="https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup</a>. Are there any other improvements planned?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Simon</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hi Simon,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks for chiming in! Let me try to clarify the current situation and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the motivation for my changes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) Initial fork of Hoopl<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Note that what I’m actually advocating is to *finish* forking Hoopl. The<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">fork really started in ~2012 when the “new Cmm backend” was being<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">finished.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">IIRC the main reason was the unacceptable performance and it seems that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">even Simon Marlow had trouble making it run fast enough:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplus.google.com%2F107890464054636586545%2Fposts%2FdBbewpRfw6R&data=02%7C01%7Csimonpj%40microsoft.com%7C4fd225e63df14788371508d4a6893eac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636316555796004376&sdata=DwwDF8h7lCAaQSzQuEJtaSGgUbvOHjrYEZoonp3BJPA%3D&reserved=0">https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance">https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The end result is pretty sad: GHC has its own forked/specialized<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">`Hoopl.Dataflow` module and is using Hoopl only for definitions of<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">`Block`/`Graph` and maps/sets (if you look at my commit, it’s pretty<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">clear what I’m copying). In particular it’s not using *any* of dataflow<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">analysis or rewriting capabilities of the Hoopl package.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) Reasons to finish forking<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The reasons I listed in my previous email already assumed the we have<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the forked `Hoopl.Dataflow` module in GHC. But if we want to discuss<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">what are reasons for forking in general, then apart from the performance<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(as noted above), there’s the issue of Hoopl’s interface. IMHO the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">node-oriented approach taken by Hoopl is both not flexible enough and it<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">makes it harder to optimize it. That’s why I’ve already changed GHC’s<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">`Hoopl.Dataflow` module to operate “block-at-a-time”<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fcommit%2F679ccd1c8860f1ef4b589c9593b74d04c97ae836&data=02%7C01%7Csimonpj%40microsoft.com%7C4fd225e63df14788371508d4a6893eac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636316555796004376&sdata=85q7qNZ9gpUFxJKEBNo6sd4qnoRV9R6ob0XJWNHuhVM%3D&reserved=0">https://github.com/ghc/ghc/commit/679ccd1c8860f1ef4b589c9593b74d04c97ae836</a>)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Some concrete examples:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- For proc-point analysis it was necessary to introduce a hack to GHC’s<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> `Dataflow` module to expose a separate analysis function that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> *ignores* the middle nodes (since for proc-points they’re irrelevant).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> My change to go “block-at-a-time” allowed us to remove that hack.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- I’m trying to fix non-linearity of `CmmLayoutStack` in<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> (<a href="https://phabricator.haskell.org/D3586">https://phabricator.haskell.org/D3586</a>) and again the block-oriented<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> interface is useful - I want to do different rewrites based on<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> which block is being considered (whether it’s a proc-point or not).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> This is not easily possible if I don’t know which block I’m in (which<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> is the case for the node-oriented interface).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I also don’t think that name clashes and the tension between Hoopl’s<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">interface and GHC are easy to solve. Hoopl is a public, stand-alone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">package, so we can’t just change things without considering<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">compatibility. For instance, we can’t use GHC’s `Unique` in Hoopl. But<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">should we switch all of GHC to use Hoopl’s? Also having closely related<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">concepts spread around GHC and Hoopl is not helping when trying to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">understand what’s happening. Finally, any changes to both GHC & Hoopl<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">have much higher overhead than just changing GHC.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In general, it really seems to me that Hoopl has been released simply<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">too early, with not enough real-world usage and testing. When you say<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">that we should “just fix Hoopl”, it sounds to me that we’d really need<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to rewrite it from scratch. And it’s much easier to do that if we can<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">just experiment within GHC without worrying about breaking other<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">existing Hoopl users. Only once we’re happy with the result, we should<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">be considering separating it into a stand-alone package.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3) Difference between pretty/containers and Hoopl<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I also think that the situation with pretty/containers is quite<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">different than Hoopl. They are much more general-purpose libraries,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">*far* more widely used and with more contributors. Take containers - the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">package is still very actively developed and constantly improved.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Whereas Hoopl hasn’t really seen much activity in the last 5 years. So<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the benefit-cost ratio is much better - yes there is some cost in having<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">containers as a dependency, but the benefits from the regular stream of<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">improvements easily outweigh it. I don’t think that’s the case for<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Hoopl.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Does this help understand my motivation? Let me know if anything is<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">still unclear!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Michal<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>