IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get
#11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Replicating here for the record my earlier email, which from my mobile phone originally went to ghc-dev@ instead: linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. A followup - I think a reasonable compromise here is simply to have: {{{ -- | Lookup in a static table constructed at compile time. unsafeLookupStaticPtr :: StaticKey -> Maybe (StaticPtr a) -- | Lookup in the static table + an aux table that's initially empty but may grow if objects are dynamically loaded. unsafeLookupStaticPtrDL :: StaticKey -> IO (Maybe (StaticPtr a)) }}} The idea is: bake in a static table at compile time that is immutable for all time; any new static pointers that get loaded at runtime (i.e. are not reachable from `main` at the start of the program) go into a separate table, which can only be accessed via `unsafeLookupStaticPtrDL`. Most programs will never use `unsafeLookupStaticPtrDL`. That way it becomes possible to define a `Binary` instance, but also address Facundo's concerns about dynamically loaded objects. I don't anticipate anyone will have time to implement the `*DL` stuff ahead of GHC 8.0, but that doesn't prevent us from moving `unsafeLookupStaticPtr` out of IO now. For the the DL table to be useful we'd have to populate it upon object load somehow, likely via so-called "constructor functions". Maybe someone with that use case wants to give it a crack (in a separate ticket). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler