Great. Could you put all this into a Trac ticket?
Thanks!
Simon
From: Alberto Valverde [mailto:albe...@toscat.net]
Sent: 08 June 2017 13:57
To: Simon Peyton Jones
Cc: GHC users
Subject: Re: 8.2.1-rc2 upgrade report
Hi Simon,
Thanks for the pointer. I re-did both builds with -dshow-passes a
> On Fri, Jun 9, 2017 at 9:50 AM Simon Peyton Jones
wrote:
> > Maybe this is the core of our disagreement - why is it a good idea to
have Hoopl as a separate package in the first place?
>
>
> One reason only: because it makes Hoopl usable by compilers other than
GHC. And, dually, efforts by other
But equally, stackage is a major part of the haskell ecosystem.
As such, implications and paths forward need to be considered.
Alan
On 9 June 2017 at 11:16, Herbert Valerio Riedel wrote:
> Hi Simon,
>
> On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs wrote:
>
> [...]
>
> >> St
Hi Simon,
On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs wrote:
[...]
>> Stackage only allows one version of each package
>
> I didn’t know that, but I can see it makes sense. That makes a strong
> case for re-doing it as a new package hoopl2
The limitations of Stackage's des
Lemme toss in my 2 cents as an outsider who likes to dabble in programming
language and compilers: I would *love* to be able just drop in (parts) of GHC's
optimisation into my toy compilers. Optimisation is complicated, lots of work,
and not really the part I care about when toying with language
Maybe this is the core of our disagreement - why is it a good idea to have
Hoopl as a separate package in the first place?
One reason only: because it makes Hoopl usable by compilers other than GHC.
And, dually, efforts by others to improve Hoopl will benefit GHC.
If I proposed extracting part
