#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 simonpj): Luite, much of what you say is cast in terms of an underlying implementation, whereas my blog post focuses as exclusively as possible on the ''specification'' of what the programmer sees. Can you recast your suggestions in those terms? For example: * What does it mean to say that "GHC should explicitly keep track of all static metadata"? How would a programmer be able to tell whether or not GHC did so. That is, what programmer-visible behaviour do you seek? * Again "It should be possible to build a list (like the Static Pointer Table) at link time for a library". This is presumably a statement about the implementation but again you must have in mind some user-visible behavior? What is it? * Again "Static names would propagate like typeclass instances". I don't really know what this means, but specifically how would a programmer know if this happened? Static names are not visible to the programmer in the design I suggest; I use them only so I can say something about a possible implementation. All the programmer sees is ordinary Haskell values and types (with one new type constructor, `StaticPtr`. * "`StaticName` should be reasonably robust..." Again, you must have in mind some user-visible behaviour. Here I think I do know what you might mean. If you have a client and server talking to one another, and you recompile one having made only small internal changes, it should still inter-work with the original client. Something like that perhaps? Clearly this isn't yet a precise statement and you might want to make it so. And so on. Do you see what I mean? On the question of "I think it would be really useful if there was a way to send type details with a more complete serialization of the construction", I don't understand well enough. I tried (perhaps inadequately) to describe a design in which type security was guaranteed without sending type representations or fingerprints at all. Of course, some higher-level guarantees might be gained by sending type reps, but that would be up to a client library built on top of the facilities GHC provides. Are you asking for any GHC support here, or simply saying something about what a client library might or might not chose to do? Sorry to be dense. Thanks Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7015#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler