[GHC] #15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes

[GHC]

#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation
and interactive modes
-------------------------------------+-------------------------------------
        Reporter:  ChaiTRex          |                Owner:
                                     |  JulianLeviston
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.6.1-beta1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Poor/confusing    |  Unknown/Multiple
  error message                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by osa1):

 As you say, `HscInterpreted` means modules are compiled to bytecode and
 then interpreted. Interpreter can interact with native code and with
 `-fobject-code` you tell GHCi to compile the loaded modules to native code
 rather than to bytecode (the default, or `-fbyte-code`).

 Either way the expressions you type in the GHCi prompt are compiled to
 bytecode and interpreted, so I think those options are only applied to the
 loaded modules. We need to avoid optimising those expressions. I think
 another (simpler) way for this might be to find the top-level function for
 compiling GHCi expressions to bytecode, and override relevant `DynFlag`
 fields there so that down the line the desugarer and simplifier do not
 optimise it. That means no new field to `DynFlags` so think it would be
 even better. If the top-level function to compile a GHCi
 expression/statement is also used for other purposes perhaps we can
 introduce a new top-level function for GHCi only, and override relevant
 `DynFlags` fields there.

 How does that sound? Sounds better to me as we don't add more to
 `DynFlags` (which is already huge).

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