Remove IntRep and WordRep (and maybe AddrRep?)

(Forked from #16964 (closed))

The PrimReps IntRep and WordRep are currently 32-bit on 32-bit systems and 64-bit on 64-bit systems. The problem is IntRep is still different than Int32Rep on a 32-bit system (and Int64Rep on 64-bit), even though they're represented the same.

The idea is to remove IntRep and WordRep so that on a 64-bit system types like Int# and Word# would have Int64Rep (and Int32Rep on 32-bit).

This simplifies the PrimRep comparison logic -- e.g. we currently have bugs when checking coercion safety when coercing a Int# (which has IntRep) to a Int64# (which has Int64Rep on 64-bit) -- see #16952 (closed). Overall having less PrimReps should make dealing with them easier.

Similarly, I think we could remove AddrRep as well -- it'd be Word32Rep or Word64Rep depending on the word size.

(Doing this is one way to fix #16952 (closed) and unblock the !1381 (closed) -- which fixes release-blocking #16893 (closed))

---

Note that PrimRep is exposed to users via GHC.Types.RuntimeRep, so this is a user-facing change (but perhaps not in a stable part of the GHC API). E.g. this program

main = print (splitApps (typeRepKind (typeRep @Int#)))

will print differently if this proposal is implemented.

---

I've started working on this -- the main difficulty is we need to pass DynFlags (or word size) to top-level constants like intPrimTyCon and wordPrimTyCon, which transitively causes a lot of things to depend on DynFlags (or word size).

cc @simonpj @bgamari

added needs triage label

mentioned in issue #16964 (closed)

Re removing AddrRep: currently we already treat word-sized types and AddrRep types the same way in primRepSlot, which is used to generate layout of unboxed sum types. (we put AddrRep types and WordRep types in the same memory locations)

Removing AddrRep would simplify that logic as well.

Thx for splitting this out

added Pnormal Ttask labels and removed needs triage label

changed milestone to %8.10.1

assigned to @osa1

Unfortunately this will require a lot of changes and probably cause performance problems.

If we remove IntRep and WordRep we'll have to update Types and TyCons for Int# and Word#: they will now depend on the target platform's word size (PlatformWordSize). We have a few options:

• Make intPrimTyCon and wordPrimTyCon take a "word size" parameter, so that on 32-bit they'll have Int32Rep/Word32Rep, and 64-bit variants on 64-bit.

  This requires passing DynFlags (or just PlatformWordSize) to large amounts of functions, and makes a lot of constants functions: intPrimTy, intPrimTyCon, and any users (transitively) will have to take DynFlags argument, which will make a lot of constants (CAFs) functions, which in turn cause losing sharing (e.g. every intPrimTy <word size> application will allocate a new TyCon and Type).

• One idea suggested by folks on IRC was to have two different TyCons for 32-bit and 64-bit Ints and Words, and only make intPrimTy/wordPrimTy parametric on word size. This has the same problems with the option above, and has a few new problems (e.g. we have to invent new Uniques for these TyCons, add new Names in PrelNames).

• The previous two solutions require passing DynFlags (or PlatformWordSize) when creating/using the Types. Another alternative is to require DynFlags when querying PrimRep of a type. This requires changing TyCon's tyConResKind :: Kind field to DynFlags -> Kind (or PlatformWordSize -> Kind). An unfortunate side effect is tyConKind :: Kind will also have to be tyConKind :: DynFlags -> Kind because the field is usually (always?) initialized with mkTyConKind binders res_kind (where res_kind is the return kind) and we only know about res_kind after applying DynFlags/PlatformWordSize to the tyConResKind.

Having wasted a lot of time with the first two options I'll now pursue the last option to see how bad it'll go. An advantage of it is that (I think) it won't cause losing sharing (although it'll still require a lot of DynFlags passing).

---

In the meantime if anyone has other ideas that'd be helpful.

Two other options:

• Have two Int# and Word# types: intPrimTy_32, intPrimTy_64, similarly for words. (@bgamari suggested this on IRC)
• Implement functions like primRepSafeToCoerce :: PlatformWordSize -> PrimRep -> PrimRep -> Bool and primRepEq :: PlatformWordSize -> PrimRep -> PrimRep -> Bool, remove Eq for PrimRep. This requires 0 refactoring in types.

Omer's points about the pain of getting rid of IntRep are well made. Which provoked me to review the goal.

In #16964 (closed) (e.g. this commentcomment) we seem to converge around making Int and Int# into distinct types.

In that case it seems to make sense to also make Int32Rep and IntRep into distinct kinds, with Int32# : TYPE Int32Rep and Int# : TYPE IntRep. Otherwise what is the kind of Int#? If it's platforms-specific we again risk not being able to write code that will work equally well on all platforms (overflow aside).

So in fact, I think that all the arguments for making Int# distinct from Int32# seem to apply equally to making their kinds distinct.

Which suggests keeping the status quo, more or less, but documenting it better.

removed milestone