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

 Here's another way to say what I mean. When in GHCi we do two kinds of
 compilation:

 - We compile loaded modules (if necessary)
 - We compile expressions typed in the GHCi prompt

 The target only makes sense for (1). In (2) we only compile to bytecode.
 So
 really `HscInterpreted` and flags like `-O` etc. are only applicable to
 (1).
 But currently we also apply some of those flags/settings to (e.g. `-O`) to
 (2)
 which is what's causing this bug.

 One of my suggestions in comment:11 was to separate these two compilations
 so
 that when we do (2) we never try to optimise the code. This can be done by
 implementing a new (or modifying the existing one if one already exists)
 top-level function for compiling GHCi expressions and updating `DynFlags`
 there
 to fix the compilation settings (e.g. by resetting optimisation level) for
 GHCi.

 Is this any more clear than my previous comment?

 > The -e and --interactive flags setup HscInterpreted as the language in
 main'
 > in Main.hs. DynFlags can be used to override this target (ie with
 -fbytecode
 > or -fobjectcode). It seems like a mistake to be able to override it when
 it's
 > already set to the HscInterpreted target, though I don't really
 understand if
 > that's actually wanted.

 So the lang/target doesn't matter when compiling GHCi expressions, as you
 _have
 to_ compile those to bytecode regardless of the lang/target. I meant
 overriding
 optimisation settings, not the lang/target.

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