#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 facundo.dominguez): {{{unsafeLookupStaticPtr}}} is not pure since the RTS can load code dynamically. Calling the function at different times of execution can yield different results. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 facundo.dominguez): {{{unsafeLookupStaticPtr}}} could be made pure if the program is forbidden from loading code dynamically. That probably will have all code depending indirectly on static pointers to work awkwardly in GHCi. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 edsko):

Hmm. I'm deeply suspicious of `StaticKey` . It plays no role in our plan of record StaticPointers. If we don't have `StaticKey` the whole issue doesn't arise.

`StaticKey` is a low-level implementation detail. I have just added support for static pointers to the existing `distributed-static` package, based on the support for static pointers that exists in ghc today. The higher level API that `distributed-static` exposes is simply that `Static a` has a `Binary` instance (for `Typeable a`). But this is precisely where the problem is: if looking up a static pointer is not pure, then we cannot give a `Binary` instance. Facundo's objection is that in fact looking up a static pointer ''isn't'' pure. If that is true, then `unsafeLookupStaticPtr` should indeed live in IO, but then not having `StaticKey` is not going to solve the problem, it's just going to move it: whatever shape the decoder of `Static` takes (`Binary` instance, separate function, ...) will have to deal with it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

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

#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 ekmett): Replying to [comment:8 mboes]:

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)) }}}

This is the approach we take in the `OpenGLRaw` package for detecting extensions. Yes, technically you ''might'' switch OpenGL contexts and change which ones are available over the life of a program, it isn't the common case, while branching on them is very common and is made nigh unusable, and needlessly slow, since they can't memoize this information if they are stuck in IO. One of hundreds of such examples: http://hackage.haskell.org/package/OpenGLRaw-3.1.0.0/docs/Graphics-GL-ARB- CullDistance.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 bgamari): I agree that being able to capture a `StaticPtr` as plain old data that can be easily serialized, like `StaticKey`, is very useful and a more natural approach than baking this logic into the compiler/standard libraries. It would be nice if the motivation and current implementation were clearly laid out in the [[wiki:StaticPointers|Wiki page]]. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2. At this point it seems less and less likely that this will happen at all given that static pointers have been out in the wild for years now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11526#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler