[GHC] #5218: Add unpackCStringLen# to create Strings from string literals

[GHC]

#5218: Add unpackCStringLen# to create Strings from string literals
-------------------------------------+-------------------------------------
        Reporter:  tibbe             |                Owner:  thoughtpolice
            Type:  feature request   |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.0.3
      Resolution:                    |             Keywords:  strings
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #5877 #10064      |  Differential Rev(s):  Phab:D2443
  #11312, #9719                      |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by winter):

 > I'm struggling to grok this ticket, especially: what is the problem we
 are trying to solve?. I'm also concerned about making things too
 complicated.

 > The ability to put a block of binary data in the program code, without
 heavy encoding.

 My understanding of this problem is that we want a way to tell ghc ''how''
 to compile literals. The ''compiler's'' interpretation of `"..."`,
 `"..."#`, `[...]` are currently fixed , and we have to do runtime
 conversion in order to get the interpretation ''we want''.

 The difference between compiler's and user's interpretation may be address
 vs heap object, or utf8 vs modified utf8 vs utf16, these difference will
 decide how codegen emit literal code.

 So we have to find a way to tell compiler what kind of interpretation we
 want, it can be via syntax, e.g. we create different syntax for different
 interpretation. Or we can use some type magic, e.g. the one i suggest. I
 believe each solution has its own pro and cons.

 In short words, i believe this is a problem
 `OverloadedString/OverloadedList` are intended to solve, but solved it
 wrong.

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