planning for ghc-6.10.1 and hackage [or: combining packages to
yield new type correct programs]
marlowsd at gmail.com
Fri Oct 3 05:01:06 EDT 2008
Don Stewart wrote:
>> Don Stewart wrote:
>>> Here's a summary of why this is non-trivial,
>>> * We're trying to compose packages on the users machine to yield new
>>> type correct programs.
>>> * We're using cabal dependencies to decide when it is safe to do this.
>>> Hopefully we don't rule in any type incorrect combinations, nor rule
>>> out to many type correct combinations.
>>> * This is scary - in fact, we think the package system admits type
>>> incorrect programs (based on Typeable, or initialised global state),
>>> as it is similar to the runtime linking problem for modules.
>> I think what you're referring to is the problem that occurs if the program
>> links in more than one copy of Data.Typeable, which would then invalidate
>> the assumptions that make Data.Typeable's use of unsafeCoerce safe. I
>> wouldn't call this "type-incorrect" - it's a violation of assumptions made
>> by Data.Typeable, not type-incorrectness in the Haskell sense.
>> But you'll be glad to know this doesn't happen anyway, because
>> Data.Typeable's state is held by the RTS these days, for exactly this
> But do the type keys into the RTS state include package versions and names?
> If so, then we're probably fine.
Good point - no it doesn't. Adding the package id to the keys would be
easy, but unfortunately the same string is used in the Show instance for
TyCon, so we'd need to fix that too.
More information about the Cvs-ghc