#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