#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