#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