<div dir="ltr">I definitely agree with what you're saying around some of the features that require external support such as backpack. <div><br></div><div>I think my statement was focused more on new language features that don't require additional support, as with stack getting access to those is as simple as hopping on the latest nightly release. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 9:38 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
On 2017-08-03 at 08:41:59 +0200, Ara Adkins wrote:<br>
<br>
[...]<br>
<span class=""><br>
> I nevertheless see `stack` as a huge boon for easing adoption of new<br>
> compiler versions (and hence new language features/extensions).<br>
<br>
</span>Since I totally disagree about Stack being beneficial to the quick<br>
adoption of new features, would you care to elaborate what makes you<br>
think that Stack was a "huge boon" in this particular context?<br>
<br>
Just to name one example where Stack has been lagging behind Cabal for<br>
several months already: Support for Backpack or convenience libraries --<br>
there's already a handful of packages on Hackage which Stack (and<br>
consequently Stackage) cannot install due to this. Being slow to adopt<br>
new features IMO makes totally sense for Stack, as it's target audience<br>
is practicioners who value stability, "reproducibility" and "long term<br>
support", so it's actually a good thing that Stack stays behind until we<br>
iron out issues with new bleeding edge features and Stack(age) adopts<br>
them only when they're officially released and deemed ready for Stack's<br>
target audience.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- hvr<br>
</font></span></blockquote></div><br></div>