[GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble
GHC
ghc-devs at haskell.org
Mon Dec 18 17:28:32 UTC 2017
#14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation
trouble
-------------------------------------+-------------------------------------
Reporter: luite | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by luite):
Replying to [comment:6 RyanGlScott]:
> Replying to [comment:5 luite]:
> > Changing it to `type Uniq = Integer` turned out to be easiest because
GHC doesn't know the data constructor for `Int64`.
>
> What do you mean by this?
GHC doesn't have the `GHC.Int.I64#` data constructor as a known name in
`PrelNames`
> > And I think `Integer` is actually more appropriate here.
>
> I'm sure `Integer` technically works, but I am worried that we'd lose
some efficiency by doing this, given how widely used `Name`s are in
Template Haskell.
I think in practice it would not make much of a difference in situations
that were already supported (i.e. target word size is the same as compiler
word size). Only the `S#` constructor would be used (the library isn't
compiled with `-funbox-strict-fields`). Maybe serialization would add an
extra tag byte and there would be some additional unused branches in the
code?
Any suggestions for a good test case for the performance impact of this
change?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14574#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list