Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How unpacking strict fields goes together with polymorphism?

The {-# UNPACK #-} pragma tells the compiler to eliminate redundant constructors. Quoting Haskell wiki:

For example, given this:

data T = T {-# UNPACK #-} !(Int,Float)

GHC will represent the type T like this:

data T = T Int Float

eliminating the tuple. This is commonly used to put unboxed Ints directly in a constructor:

data T = T {-# UNPACK #-} !Int

will be represented as

data T = T Int#

I was wondering, does this also work when the field to be unpacked is polymorphic? For example, if I define

data S' a   = S String {-# UNPACK #-} !a

type S1     = S' Int
newtype S2  = S2 (S' Int)

will functions that work with S1 or S2 be optimized?

like image 899
Petr Avatar asked Oct 27 '12 08:10

Petr


1 Answers

Quoting from Don's blog about unpacking

It does not make sense for polymorphic fields, since they have variable size, and the compiler does not (except in very specific circumstances) have access to information about what types are in use.

Also you can read Tibell's reply to mailing list.

Unfortunately unpacking doesn't work for polymorphic fields (the new warning for ineffective unpack pragmas in GHC head should warn about this) ...

like image 172
Satvik Avatar answered Oct 02 '22 16:10

Satvik