[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 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