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 <davidte...@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@projects.haskell.org > http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform -- Push the envelope. Watch it bend. _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
