Remove the Full constructor

[sjakobi]

Closes #399.

---

TODO:

• Run the full benchmarks and compare the results
• Remove bitmapIndexedOrFull
• Remove mentions of Full
• Remove Full-specific functions
• Update util/Stats.hs

[sjakobi]

First impressions:

• The code size reductions are mostly moderate, except with union and intersection where they are quite enormous.
• fromList gets slightly slower
• lookup seems to get slightly faster (~5%) in maps that didn't have a Full constructor to begin with. But for large maps I'm seeing slowdowns of up to ~15% (All.HashMap.Strict.lookup.presentKey.Int.10000: 13 ns -> 15 ns).

[treeowl]

Very nice! Did you check to make sure you haven't broken an assumption anywhere that a BitmapIndexed node isn't full? That's what intimidated me about this particular project.

[treeowl]

I'm surprised by the lookup regression. Any guesses about why?

[sjakobi]

Did you check to make sure you haven't broken an assumption anywhere that a BitmapIndexed node isn't full?

I rely on the "valid" property tests. It would probably be a good idea to check the test coverage again (#270).

I'm surprised by the lookup regression. Any guesses about why?

In Full nodes it's very simple to find the right array index:

unordered-containers/Data/HashMap/Internal.hs

Lines 2438 to 2439 in 53ffd98

	index :: Hash -> Shift -> Int
	index w s = fromIntegral $ unsafeShiftR w s .&. subkeyMask

In BitmapIndexed nodes the computation is more involved:

unordered-containers/Data/HashMap/Internal.hs

Lines 2459 to 2467 in 53ffd98

	sparseIndex
	:: Bitmap
	-- ^ Bitmap of a 'BitmapIndexed' node
	-> Bitmap
	-- ^ One-bit 'mask' corresponding to the 'index' of a hash
	-> Int
	-- ^ Index into the array of the 'BitmapIndexed' node
	sparseIndex b m = popCount (b .&. (m - 1))
	{-# INLINE sparseIndex #-}