Changes to GHC that will expose new packages

[Thomas Schilling]

Could you explain what that API will look like?  E.g., why does the
*library* need to depend on haskeline instead of just the executable?
I think a GHCi API should expose the commands of GHCi, but not the
command line interface of the ghci executable.  At least that's what
my plans were for such an API (which would have been a package not
bundled with GHC).

I really don't like adding package dependencies to GHC because it now
means that package is tied to GHC's release schedule.  (That is unless
the dependency is truly internal, but then why does the GHCi library
depend on them?)

If the new packages are really necessary then I'd prefer using the
(automated) renaming with the "ghc-" prefix.

On 21 March 2012 17:47, David Terei <davidterei at gmail.com> wrote:
> Hi all,
>
> We are currently contemplating some changes to GHC that will
> unfortunately mean we'll need to include these packages: haskeline,
> mtl, terminfo & utf8-string. We wanted to check what the implications
> for the haskell platform were and if you had any advice.
>
> The reason for this is that we want to expose an API for ghci. ghci
> relies on haskeline and through that mtl, terminfo & utf8-string.
> Previously ghci was just built as a binary with no library component,
> so its dependencies didn't matter.
>
> Cheers,
> David
>
> _______________________________________________
> Haskell-platform mailing list
> Haskell-platform at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform



-- 
Push the envelope. Watch it bend.