ghc
ghc copied to clipboard
Unrestricted values in primitive data types
Make the data types Double, Float, Char, Ptr, Int{N}, and Word{N} be unrestricted in the unboxed argument in their data constructor. This is related to the discussion in https://github.com/tweag/ghc/issues/179.
Weird. This works for the types defined in GHC.Int but not for things from GHC.Word or GHC.Types. In ghci, I can confirm this with:
>>> :info Word8
data Word8 = W8# ghc-prim-0.5.3:GHC.Prim.Word#
-- Defined in ‘GHC.Word’
>>> :info Int8
data Int8 where
I8# :: ghc-prim-0.5.3:GHC.Prim.Int# -> Int8
-- Defined in ‘GHC.Int’
>>> :info Int
data Int = I# ghc-prim-0.5.3:GHC.Prim.Int#
-- Defined in ‘ghc-prim-0.5.3:GHC.Types’
The data constructor for Int8 is unrestricted like it should be. The data constructors for Word8 and Int are not.
It may be an avatar of #169 , though (or another printing issue). I don't think I've modified any of this: do you mean that you have tried to make this modification and that's what you observe in your patch?
Yes. I've modified all of these data constructors in the PR. It's not just the printing. I get multiplicity errors when I try to consume Int linearly by pattern matching on it and using the internal Int# multiple times. However, if I do the same thing with Int64, it works fine. The weirdest part is the fixed-size integer types behave as I expect them to, but fixed-size word types don't. I tried make clean and totally rebuilding because I'm worried I just messed up the build somehow. I'm going to try on another computer this evening.
Ah… sorry, I had opened this from my email and didn't realise it was a PR rather than an issue. Obviously: sleep is neeed.
It could have happened if you had forgotten to add -XLinearTypes to some of these files. But it doesn't appear to be the case. So I'm equally puzzled.
Come to think of it, I don't think we can merge this yet, because the CPR worker-wrapper split (which is critical for numerical computation) is deactivated for unrestricted constructors. I'm, obviously, not allowed to merge such a performance regression.
Gotcha. I'll keep trying to figure out why this is messed up, and whenever worker-wrapper gets fixed, hopefully, this should be ready to merge.