Simon Marlow wrote:
If the base package is upgraded without also replacing the other
libraries... this is where it gets really tricky. Binary
dependencies between library code tend to be very deep due to
cross-module inlining and optimisations, so right now the chances of
upgrading base without replacing everything else are almost zero. To
be able to do this I believe we have to track very carefully the
API/ABI that a package is exposing, so that we can be sure that a
replacement is truly compatible. This may mean restricting
optimisations across package boundaries.
I think it would be a great pity to sacrifice any optimizations, if it was
at all possible to simply reconfigure/rebuild/reinstall all the existing
packages on one's system after upgrading ghc.
As long as there was a tool to automatically do this it wouldn't be a big
deal.
Perhaps packages which are not in ghc core which depend on the RTS (perhaps
indirectly via other C libs they link to which call into Haskell) could be
explicitly marked as such, so the user could manually check to see if the
package had been tested with the latest ghc, or if there was an updated
version to download (hopefully this could be automated using a central
database of all known packages).
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
