[GHC] #7015: Add support for 'static'

[GHC]

#7015: Add support for 'static'
-------------------------------------+-------------------------------------
              Reporter:  edsko       |            Owner:
                  Type:  feature     |           Status:  patch
  request                            |        Milestone:  7.10.1
              Priority:  normal      |          Version:  7.4.2
             Component:  Compiler    |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:              |  Related Tickets:
  None/Unknown                       |
             Test Case:              |
              Blocking:              |
Differential Revisions:  Phab:D119   |
-------------------------------------+-------------------------------------

Comment (by luite):

 I agree with simonpj and rwbarton. My suggestion in the phab discussion
 (generating foreign exports) was merely something that could be done with
 the current tools, but now that the patch is going to be
 rewritten/improved there may be better options.

 Other than getting memory management sorted out, I think these are the
 minimum requirements to make it possible to implement static values
 properly on different backends:

   * GHC should explicitly keep track of all static metadata (hi files
 probably)
     * Static names would propagate like typeclass instances
     * It should be possible to build a list (like the Static Pointer
 Table) at link time for a library or program (and if desired, build a
 program that can produce this list at runtime)
   * `StaticName` should be reasonably robust against minor variations
 between compiles/backends
     * no backend/platform specific internal names
     * a source code location as an identifier for generated names is
 better than a simple counter
     * at least some simple safeguard against constructing an ill-typed
 heap object (like a type fingerprint) should be there

 As an aside, I think it would be really useful if there was a way to send
 type details with a more complete serialization of the construction (in
 terms of `Typeable`/`TypeRep` or similar) in the `StaticName` or at a
 higher level:
   * It would be possible to generate a more readable type error message if
 a fingerprint does not match (rather than using `show` on both sides)
   * Languages like Python and JavaScript could dynamically convert values
   * In conjunction with `GHC.Generics` or `Data.Data` one could use this
 to generate user interfaces that allow typesafe structured
 construction/editing of arguments (and dictionaries, when supported)

 And a final point on my wish list: It would be very useful if the `static`
 keyword for toplevel bindings would result in a `StaticName` that uses the
 original function name, rather than some generated name:

 {{{
 #!haskell
 import qualified Data.Map as M

 -- this would guarantee that concat is in the static list
 concat :: [[a]] -> [a]
 concat = static (foldr (++) [])

 -- for functions that do pattern matching we could introduce a pragma
 {-# STATIC and #-}
 and :: [Bool] -> Bool
 and []          =  True
 and (x:xs)      =  x && and xs

 -- or for exposing functions from other modules
 {-# STATIC M.fromList #-}
 }}}

 This would make it easier to have asymmetric CH programs, where one part
 is merely the callee, but does not include the code where the result from
 the call is used. I think this could also useful to implement a more
 flexible foreign exports mechanism for GHCJS, see
 https://github.com/ghcjs/ghcjs/issues/194 for some discussion.

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