[GHC] #15395: Make StaticPtr (more) robust to code changes and recompilation

[GHC]

#15395: Make StaticPtr (more) robust to code changes and recompilation
-------------------------------------+-------------------------------------
           Reporter:  richardw       |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  normal         |         Milestone:  8.6.1
          Component:  Compiler       |           Version:  8.4.3
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Discussion migrated from
 [https://www.reddit.com/r/haskell/comments/8z86q6/stability_of_staticptr/
 this] thread on Reddit.

 The [http://hackage.haskell.org/package/base-4.11.1.0/docs/GHC-
 StaticPtr.html documentation] for GHC.StaticPtr states that "Only
 processes launched from the same program binary are guaranteed to use the
 same set of keys."

 On the other hand, this
 [https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers blog post]
 by Simon suggests that the only sensible implementation of StaticPtr would
 be as (essentially) a package/module/identifier name triple, which sounds
 right to me. In this case two StaticPtrs should share the same key as long
 as they are in the same package/module and assigned to the same
 identifier.

 My use case is similar to the one described
 [http://neilmitchell.blogspot.com/2017/09/existential-serialisation.html
 here], where StaticPtr is used for (de)serialization of an existential.
 As pointed out in the comments to that post, this approach could break
 upon any recompilation of the code base.

 Having static pointers stable only across instances of the same binary
 also seems like it would be a potential problem for the applications like
 CloudHaskell that StaticPointers was developed for.  Presumably this means
 means all nodes need to be based on the same architecture and updates need
 to happen on every node simultaneously.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15395>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler