Upgradeable base (smallest step forward)

[Joachim Breitner]

Hi,

I have not given up on my ideas for split base; just always had more
important things on my mind, and the task is daunting...

But motivated by the other thread, I wonder: What is the smallest
possible, useful step in the direction? In particular, is there a way
that we can make base upgradable with simple changes (documentation
improvements, or the addition of fromLeft discussed here, or bugfixes)
independent of ghc?

This is how it might work. Split base into two (name shedding
deferred):

 * base-foo

   This package, hidden by default, contains all the relevant data type
   and class definitions, and some of the functions definitions (see 
   below).

 * base

   This package re-exports stuff from base-foo, either on the symbol or
   the module level, and provides the kitchen sink interface that we
   are used to. This is what normal code out there is supposed to use.

The idea is now that base-foo is tied to GHC. This means that ghc, and
all libraries that ghc depend upon, use base-foo. Functionality
required to make that compile can be moved to base-foo, and then either
re-exported in base, or re-implemented in base.

This would allow us to apply non-invasive changes (basically everything
that does not change data types, class definitions or instances that
had to be included in base-foo) without changing ghc.

base could even be a normal cabal package that does not even have to be
shipped with GHC (we might want to ship it for convenience).


This is of course a rough sketch, but I hope it is concrete enough that
you can tell me why it does not work :-)


Greetings,
Joachim



--
Joachim “nomeata” Breitner
  ma...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nom...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nom...@debian.org

[Michael Snoyman]

I've been thinking about this myself a bit as well, and I like this approach. Two questions:

* I'd like to make sure we're on the same page with what would be part of "base-foo". Are we talking about basically anything that is a special type or class from GHC's perspective? I'd see Monad and MonadFail being there for do-notation, and by necessity pull in Functor and Applicative as superclasses. But Alternative would not be there, since there's nothing tying it into GHC, nor would Monad-specialized functions like `liftM`.

* Would it make sense to just throw these type classes into ghc-prim?

As an ultimate goal for a project like this, it would be nice if you could do something like upgrade your base package but continue to use the ghc package without incompatible types. That would likely involve moving types like ByteString into ghc-prim or somewhere else shared, which is why I'm glad you've positioned such a clear first step of just being able to build base as a normal package.

--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Herbert Valerio Riedel]

On 2016-06-05 at 14:35:47 +0200, Joachim Breitner wrote:

[...]

>  * base
>
>    This package re-exports stuff from base-foo, either on the symbol or
>    the module level, and provides the kitchen sink interface that we
>    are used to. This is what normal code out there is supposed to use.
>
> The idea is now that base-foo is tied to GHC. This means that ghc, and
> all libraries that ghc depend upon, use base-foo. Functionality
> required to make that compile can be moved to base-foo, and then either
> re-exported in base, or re-implemented in base.

I generally like the direction, `base` is in desperate need of
restructuring, but I strongly disagree with "This is what normal code

out there is supposed to use".

One problem we have with `base` is that it's too monolithic, and
contains too many GHC-isms. This forces us to perform major versions
bumps for every major GHC release even if just a single exposed
type-signature changes and which maybe only very few packages use out
there even use.

While this is mostly a nuisance and mostly results in busy work for
either package authors or falls back to Hackage Trustees (and
occasionally fuels our favorite PVP debates), the way more serious issue
is the fact that `base` in its current form is highly non-portable.

Since Hackage is essentially a `base`-centric ecosystem, alternate
non-GHC compilers, or more realistically GHCJS & GHCJVM are forced to
provide a `base` package if they want to join in.

But this means that the `base-4.9.0.0` package those compilers claim to
provide can't honestly supply the API promised by the `base-4.9.0.0`
contract. To some degree, even with Windows we have this already now,
where GHC resorts to a conditional API

-- OS Specific
if os(windows)
reexported-modules:
GHC.IO.Encoding.CodePage.API,
GHC.IO.Encoding.CodePage.Table,
GHC.Conc.Windows,
GHC.Windows
else
reexported-modules:
GHC.Event

And I believe we can all agree that conditional APIs lead to headaches
on various levels, and are highly undesirable if we want to have a
package version number capture its exposed API surface in a meaningful
way.

As a Hackage-trustee hat on with the mission to have .cabal files
capture accurate information for the cabal solver, and therefore allow
Hackage to reduce its entry barrier for alternative compilers, or even
GHC-flavours this is a real problem, as currently we have to rely on
version numbers to capture the exposed API signature accurately. Maybe
Backpack will provide additional tools to address this, but even with
Backpack in its current specification I don't see a way to avoid
accurate version numbers completely.

Right now, this issue may not be that apparent as the only major
non-uniformity is caused by the Windows platform (and I always worry I
may inadvertently break it when I edit `.cabal` files on Hackage, but so
far nobody complained...). However, if ghcjs & ghcjvm start gaining
popularity, the problem will become more apparent. And if `base`'s
version stops capturing its API I may not be able to perform my Hackage
Trustee tasks anymore.

Long story short, I'd like `base` to be in a better shape for when those
GHC projects start to gain traction. Consequently, I'd rather see
"normal code out there" start using a more portable default base-library
in the long run, rather than keep up the tradition on depending on a
kitchen sink interface providing highly platform specific or conditional
APIs.

I honestly doubt that the majority of packages really need more than a
very small subset of `base`, and that subset is most likely a rather
platform-agnostic one. And I think it should be easy to go through
Stackage as a represntative sample, and collect the data to see which
non-portable parts are *really* imported from `base`, and use that as
guidance to design a new 80/20-rule `base`-package "normal code out

there is supposed to use".

Cheers,
HVR

[Joachim Breitner]

Hi,

Am Sonntag, den 05.06.2016, 16:13 +0300 schrieb Michael Snoyman:
> I've been thinking about this myself a bit as well, and I like this
> approach. Two questions:
>
> * I'd like to make sure we're on the same page with what would be
> part of "base-foo".

My answer is: It does not matter a whole lot! This package is going to
be used by ghc and ghc’s dependencies, and of course by base, but
ideally not by any one else.

It has to contain at least
 * Everything that is GHC-baked in (Monad, List, etc.)
 * Everything that is part of the API of the ghc package, and
   the other few packages that have to depend on it.

But it can contain more, and it would not matter. In fact, we could
start by simply copying all of base (as of now), and re-exporting
everything in "base", and then making changes to base as we go on.

> Are we talking about basically anything that is a special type or
> class from GHC's perspective? I'd see Monad and MonadFail being there
> for do-notation, and by necessity pull in Functor and Applicative as
> superclasses. But Alternative would not be there, since there's
> nothing tying it into GHC, nor would Monad-specialized functions like
> `liftM`.

It would not have to e in there, but it can.

> * Would it make sense to just throw these type classes into ghc-prim?

Possibly. But, at least to me, ghc-prim is "small package with place
for deep magic".

> As an ultimate goal for a project like this, it would be nice if you
> could do something like upgrade your base package but continue to use
> the ghc package without incompatible types.

Right! That is the goal.

> That would likely involve moving types like ByteString into ghc-prim
> or somewhere else shared, which is why I'm glad you've positioned
> such a clear first step of just being able to build base as a normal
> package.

In my proposal, ByteString would stay in bytestring, but the bytestring
package would use the base-foo package, so that an upgrade of base
would not affect bytestring.

[Herbert Valerio Riedel]

On 2016-06-05 at 15:13:53 +0200, Michael Snoyman wrote:

[...]

> As an ultimate goal for a project like this, it would be nice if you could
> do something like upgrade your base package but continue to use the ghc
> package without incompatible types.

That's one way to approach this. However, I've been experimenting with a
more flexible way: Thanks to cabal-1.24's new nix-based tech-preview
which gets rid of that `--force-reinstall` abomination for good, the
prospect of simply recompiling the `ghc` cabal package becomes more
attractive.

This would get rid of the primary reason which currently constraints us
to using the package versions bundled in GHC (like e.g. for
`bytestring`) as soon as `ghc` enters an install-plan.

I'm still investigating this, but early experiments were promising, but
I need to reorganise GHC's source-tree a little bit to know for sure if
this is feasable. But if this as I hope is possible, this could open up
a lot of new possibilities!

[Joachim Breitner]

Hi,

Am Sonntag, den 05.06.2016, 18:34 +0200 schrieb Herbert Valerio Riedel:
> Long story short, I'd like `base` to be in a better shape for when those
> GHC projects start to gain traction. Consequently, I'd rather see
> "normal code out there" start using a more portable default base-library
> in the long run, rather than keep up the tradition on depending on a
> kitchen sink interface providing highly platform specific or conditional
> APIs.
>
> I honestly doubt that the majority of packages really need more than a
> very small subset of `base`, and that subset is most likely a rather
> platform-agnostic one. And I think it should be easy to go through
> Stackage as a represntative sample, and collect the data to see which
> non-portable parts are *really* imported from `base`, and use that as
> guidance to design a new 80/20-rule `base`-package "normal code out
> there is supposed to use".

You describe very much my goals with splitting base, as outlined on the
wiki page. What I am proposing in this thread is just a small step in
that direction, solving one problem (the inability to make small
changes to base without a GHC release). I am not tackling the whole
thing at once, because that didn’t happen in the past.

BTW, people can already provide smaller sections of base and give them
package names,  re-exporting modules that (currently) live in base.

[Herbert Valerio Riedel]

On 2016-06-05 at 23:52:39 +0200, Joachim Breitner wrote:

[...]

> I am not tackling the whole thing at once, because that didn’t happen
> in the past.

That's understandable. My rant was mostly triggered about that comment
about recommending the normal code out there ought to use `base`, which
seemed to deviate from the original intent you layed out on the
wiki-page.

> BTW, people can already provide smaller sections of base and give them
> package names,  re-exporting modules that (currently) live in base.

Indeed, we can do this properly since GHC 7.10/cabal-1.22. But how do
we create enough incentive (or dually, create enough discouragement) to
break the inertia of people to keep using the non-portable `base`, and
force ghcjs/ghcjvm et al to either lie about `base` or be excluded from
Hackage?

I'm willing to invest and contribute energy to analyse packages and come
up with a reasonably portable subset of `base`. But I'm not motivated to
do this, unless there's some level of committment endorse this, and to
discourage using the current non-portable `base` (which imho should
really be called `ghc-base` instead) by default, once such a
portable-`base` shim package has been implemented.

[Joachim Breitner]

Hi,

Am Montag, den 06.06.2016, 00:25 +0200 schrieb Herbert Valerio Riedel:
> On 2016-06-05 at 23:52:39 +0200, Joachim Breitner wrote:
>
> [...]
>
> > I am not tackling the whole thing at once, because that didn’t happen
> > in the past.
>
> That's understandable. My rant was mostly triggered about that comment
> about recommending the normal code out there ought to use `base`, which
> seemed to deviate from the original intent you layed out on the
> wiki-page.

ok, replace “recommendation” by “currently observed practice that we do
not necessarily have to change at this point” :-)

> > BTW, people can already provide smaller sections of base and give them
> > package names,  re-exporting modules that (currently) live in base.
>
> Indeed, we can do this properly since GHC 7.10/cabal-1.22.  But how do
> we create enough incentive (or dually, create enough discouragement) to
> break the inertia of people to keep using the non-portable `base`, and
> force ghcjs/ghcjvm et al to either lie about `base` or be excluded from
> Hackage?

This is a very tricky question. One could say: If people would not
happily use more declarative subsets of base, then maybe the system is
not broken? If we need to force/trick/lure them into a new system, is
that a good thing?

OTOH, there is always more inertia than what can be attributed to
people choosing in their best interest, and a good idea might need a
little push.

> I'm willing to invest and contribute energy to analyse packages and come
> up with a reasonably portable subset of `base`.

I have done some analysis of that sort a while ago; it might serve as a
a starting point:
https://mail.haskell.org/pipermail/libraries/2013-July/020421.html

> But I'm not motivated to
> do this, unless there's some level of committment endorse this, and to
> discourage using the current non-portable `base` (which imho should
> really be called `ghc-base` instead) by default, once such a
> portable-`base` shim package has been implemented.

The lack of clear committment is what made me turn to other projects
three years ago. So if you want this, you might have to do it based on
your own committment only. This may work; the stackage guys did it like
that :-)

[Simon Peyton Jones]

* Would it make sense to just throw these type classes into ghc-prim?

There’s a bit of explanation in

            https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries

towards the end “Boot packages dependencies”.

 

ghc-prim has just enough to support the integer-gmp/integer-simple package.  You can’t just “throw these type classes into ghc-prim” if any of them mention Integer.

 

Other dependencies are mentioned just below in the same section, notably exceptions for incomplete patterns.

 

These dependencies are sometimes Not Obvious, so let’s document what we learn in this wiki page (or equivalent).

 

It’s worth noting also the difference between “wired-in things” (a pretty strong dependency) and “known-key things” (a much weaker dependency).

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn

 

Simon

[ezy...@mit.edu]

On Monday, June 6, 2016 at 1:47:28 AM UTC-7, Simon Peyton-Jones wrote:
> It’s worth noting also the difference between “wired-in things” (a pretty strong dependency) and “known-key things” (a much weaker dependency).
>
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn

Chiming in a bit here, since I have done some experiments with completely retargetable base: in principle, base is ALREADY upgradeable, assuming that all of the known-key things are put in the same places GHC expects them, e.g., https://ghc.haskell.org/trac/ghc/ticket/10266 However, it's not easy to do so (since Cabal will refuse to try to rebuild base--it's usually not what you want.)

The big thing is that all known-key things have to be in the same place that GHC expects them to be--and that is hard-coded. (All wired-in things live solely in ghc-prim.)

This doesn't solve problems when you want ghc to be part of the build-plan; but that's what hvr's "rebuild GHC on the fly" idea is all about.

[Joachim Breitner]

Hi,

Am Montag, den 06.06.2016, 21:29 -0700 schrieb ezy...@mit.edu:
> On Monday, June 6, 2016 at 1:47:28 AM UTC-7, Simon Peyton-Jones
> wrote:
> > It’s worth noting also the difference between “wired-in things” (a
> > pretty strong dependency) and “known-key things” (a much weaker
> > dependency).
> >
> > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn
>
> Chiming in a bit here, since I have done some experiments with
> completely retargetable base: in principle, base is ALREADY
> upgradeable, assuming that all of the known-key things are put in the
> same places GHC expects them, e.g., https://ghc.haskell.org/trac/ghc/
> ticket/10266 However, it's not easy to do so (since Cabal will refuse
> to try to rebuild base--it's usually not what you want.)

an interesting bit of information. What precisely do you mean by “same
place”?
Is it "the currently exposed package called base + module name"?

So what would happen if I would build a a new minor version of base
with cabal – could I use it just normal, as long as I don’t have "ghc"
in the build plan?

> This doesn't solve problems when you want ghc to be part of the
> build-plan; but that's what hvr's "rebuild GHC on the fly" idea is
> all about.

So, in extension, if that idea works out, suddenly all problems (wrt.
upgrading base) are gone?

Fancy prospect.

[ezy...@mit.edu]

On Tuesday, June 7, 2016 at 12:29:03 AM UTC-7, Joachim Breitner wrote:
> an interesting bit of information. What precisely do you mean by “same
> place”?
> Is it "the currently exposed package called base + module name"?
>
> So what would happen if I would build a a new minor version of base
> with cabal – could I use it just normal, as long as I don’t have "ghc"
> in the build plan?

In principle, but cabal-install is hard-coded to not try rebuilding base. It might be as simple as dropping "base" from requireInstalled in cabal-install/Distribution/Solver/Modular/Solver.hs

Prompted by this, I tried rebuilding base using Cabal. Actually it worked quite fine. Inside base:

$ ghc-8.0 --make Setup.hs -i
$ ./Setup configure -w ghc-8.0 -f integer-gmp
$ ./Setup build
$ ghc-8.0 --make A.hs -package-db dist/package.conf.inplace -package-id base-4.9.0.0-AKFoZ3gYX0UJUaqe81gldS -i

I modified base and verified that my build of `A.hs` picked up the new version.

It's worth noting that base is VERY sensitive to the version of GHC. I couldn't build the most recent ghc-8.0 branch of base with an RC of GHC 8.0, because actually someone fixed a bug after one of the RCs (9c48d8a02dd80bba3bd313bc52add841530e28dc) and removed the workaround for a GHC bug that afflicted the RC that I was using.

> > This doesn't solve problems when you want ghc to be part of the
> > build-plan; but that's what hvr's "rebuild GHC on the fly" idea is
> > all about.
>
> So, in extension, if that idea works out, suddenly all problems (wrt.
> upgrading base) are gone?

Yes, should be.

[Joachim Breitner]

Hi,

Right, we currently are quite lazy in base with regard to ghc
compatibility, because why shouldn’t we. But it should be possible to
get a handle on that; for example with automatic tests against various
versions of GHC on travis, just like for any other library.

> > > This doesn't solve problems when you want ghc to be part of the
> > > build-plan; but that's what hvr's "rebuild GHC on the fly" idea is
> > > all about.
> >
> > So, in extension, if that idea works out, suddenly all problems (wrt.
> > upgrading base) are gone?
>
> Yes, should be.

Cool. Hvr, here is a bag of motivation to work on that idea: 🛍

[Herbert Valerio Riedel]

Hi everyone,

As part of the recent GHC 8.2.1 release and the associated boot-library
publishing to Hackage, I picked up again experimenting with a
reinstallable lib:ghc package primarily for the benefit of uploading
haddocks for lib:ghc (w/ `--hyperlinked-source`) to Hackage:

http://hackage.haskell.org/package/ghc

However, this also provides somewhat of a tech-preview of a
reinstallable lib:ghc package, which would help mitigate a big issue we
had in the past with lib:ghc and its dependencies being frozen to
specific versions, and which in combination with cabal's nix-style
pkg store that finally provide us with the ability to have multiple
instances of the same library versions co-existing in the same package
db, is no longer a requirement. So we could have lib:ghc more easily pick
dependencies up (but still within reason!) like e.g. lib:text without
forcing everyone to the single lib:text version bundled with GHC. And
we'd also gain the ability to publish patch-level releases to lib:ghc
only inbetween proper minor GHC releases (e.g. to support new versions
of library dependencies).

Consider this artificial example demo package which requires a different
version of binary than the one bundled with GHC 8.2.1:

--8<---------------cut here---------------start------------->8---
-- ghc-demo.cabal
name: ghc-demo
version: 0
build-type: Simple
cabal-version: >=2.0

executable ghc-demo
main-is: Main.hs
build-depends: base ^>= 4.10, ghc ^>= 8.2.1, binary == 0.8.5.0
default-language: Haskell2010
--8<---------------cut here---------------end--------------->8---

Trying to build this will have the cabal solver complain that the
installed instance of ghc requires a different (& installed) version of
binary, i.e. binary-0.8.5.1.

Moreover, the source version of lib:ghc on Hackage has the manual
`buildable` cabal flag which defaults to false, and currently prevents
lib:ghc to be reinstalled automatically (by enabling an unsatisfiable
constraint):

--8<---------------cut here---------------start------------->8---
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: base-4.10.0.0/installed-4.1... (dependency of ghc-demo-0)
next goal: ghc (dependency of ghc-demo-0)
rejecting: ghc-8.2.1/installed-8.2... (conflict: binary==0.8.5.0, ghc => binary==0.8.5.1/installed-0.8...)
trying: ghc-8.2.1
rejecting: ghc-8.2.1:-buildable (conflict: base==4.10.0.0/installed-4.1..., ghc -buildable => base<0)
rejecting: ghc-8.2.1:+buildable (manual flag can only be changed explicitly)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: ghc-demo, binary, base, ghc, ghc-8.2.1:buildable
--8<---------------cut here---------------end--------------->8---

However, if we unlock this by toggling the flag (NB: this only works on
linux/x86_64; it's explained later why), e.g.

--8<---------------cut here---------------start------------->8---
-- cabal.project file
packages: .

package ghc
flags: +buildable
--8<---------------cut here---------------end--------------->8---

The cabal solver would come up with an install-plan:

--8<---------------cut here---------------start------------->8---
Resolving dependencies...
Build profile: -w ghc-8.2.1 -O1
In order, the following will be built (use -v for more details):
- binary-0.8.5.0 {binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac} (lib) (requires download & build)
- ghc-boot-8.2.1 {ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb} (lib) (requires build)
- ghci-8.2.1 {ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1} (lib) (requires build)
- ghc-8.2.1 {ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c} (lib) +buildable (requires build)
- ghc-demo-0 {ghc-demo-0-inplace-ghc-demo} (exe:ghc-demo) (first run)

Configuring binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib)
Building binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib)
Installing binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib)
Finished binary-0.8.5.0-7f686cf5c40c3c685540306709c4a2a30d740679f5d31ad196283d242a4d70ac (lib)
Configuring ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib)
Building ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib)
Installing ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib)
Finished ghc-boot-8.2.1-7930c3d78690c5fa476415d38abbb7717b05cf65e80cc79c12e782c9886507cb (lib)
Configuring ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib)
Building ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib)
Installing ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib)
Finished ghci-8.2.1-6292924619a045fd18e9fde0cfa350632672ad7439cb84a5c56ff0e4781346b1 (lib)
Configuring ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)
Building ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)
Installing ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)
Finished ghc-8.2.1-bc10931b0f169622deb74d84cf10e315730dfd8f2edcf4cad9073d142cf5da0c (lib)

Configuring executable 'ghc-demo' for ghc-demo-0..
Preprocessing executable 'ghc-demo' for ghc-demo-0..
Building executable 'ghc-demo' for ghc-demo-0..
[1 of 1] Compiling Main ( Main.hs, /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo-tmp/Main.o )
Linking /tmp/lll/dist-newstyle/build/x86_64-linux/ghc-8.2.1/ghc-demo-0/c/ghc-demo/build/ghc-demo/ghc-demo ...
--8<---------------cut here---------------end--------------->8---


So, cabal was able to succesfully produce an executable which uses a
reinstalled lib:ghc w/ a different lib:binary version!


But now for the limitations: this currently works at best with a GHC
8.2.1 installation whose configuration matches the generated files I
manually included in the modified lib:ghc package in

http://hackage.haskell.org/package/ghc-8.2.1/src/autogen/

which as you can see from the generated files (see e.g. Config.hs) was a
Linux/x86_64/libgmp/internal-libffi/... configuration.

...and this finally brings me to the purpose of why I wrote this email:
In order to make lib:ghc properly reinstallable we'd need to either

a) have a way to regenerate the files autogen/* via a custom Setup.hs
(by the likes of genprimcode or similiar)

or the lazy option,

b) simply have those files installed in a place we can easily locate
(again, from a custom Setup.hs)

Does this make any sense; which option do you prefer?

Also, I'd like to know if you can think of reasons why or situations
when the reinstalled lib:ghc wouldn't work; or other reasons why this is
a bad idea.


Cheers,
hvr