Re: heads-up: Haskell updates

[Timothy Sample <samplet@ngyro.com>]

Ricardo Wurmus <rekado@elephly.net> writes:

> I think that’s a misunderstanding.  The cause for the error is earlier
> when it complains that some packages depend on different versions of the
> “transformers” package.  “StateT” is a monad transformer.

For what it’s worth, I fixed this error on my machine by adding
“ghc-transformers” as an input to “ghc-transformers-compat”.  (This also
fixed “ghc-adjunctions”.)  This suggests to me that what you wrote
earlier accounts for the problem:

> * many problems are caused by the fact that GHC includes a bunch of
>   packages that really shouldn’t be overridden by packages.  Examples
>   are ghc-directory, ghc-binary, ghc-bytestring, etc.  Since we still
>   have packages where these inputs are used, there can be conflicts down
>   the line, which are hard to fix.

The “ghc-transformers-compat” package was using “transformers” from GHC,
while “resourcet” and “adjunctions” used our “ghc-transformers” package
from Hackage.  Forcing “ghc-transformers-compat” to also use
“transformers” from Hackage fixes the problems.

I was trying to see if I could get Idris to build, and after fixing
these two packages, ran into similar problems with “ghc-binary”.

It looks like we might need some kind of policy here.  Either we don’t
tinker with (override) the built-in GHC packages or we somehow hide them
during builds.  If we decided not to override them, we should consider
deleting all the packages that do so.  Then all the dependent packages
would pick up their dependencies from GHC (somewhat implicitly).  If we
hid the built-in packages, it would require that every Haskell package
be explicit about which built-in GHC packages it uses (which is not
currently the case as demonstrated above).

Both of these approaches would probably cause a lot of errors right off
the start.  The first approach would cause compile-time errors
(references to undefined variables in Guile), and the second, build
errors.

Unfortunately, I don’t know enough about Haskell to comment on whether
or not these packages “really shouldn’t be overridden” or not.  (It
makes sense to me, but OTOH, why are they all split up and on Hackage if
not for tinkering?)  If they really shouldn’t be overridden, then we
should stop doing so!

I’m happy to work on this if there is a path forward.

Thoughts?


-- Tim