[GHC] #15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes
GHC
ghc-devs at haskell.org
Mon Sep 24 05:45:42 UTC 2018
#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
More information about the ghc-tickets
mailing list