Using Strict and StrictData by default

[kazu-yamamoto]

To avoid unexpected behavior, let's use Strict and StrictData for version 4. This PR include:

• Introducing the lazy binding for sizeOf and alignment where undefined is typically passed.
• Removing undefined as much as possible.

Discussion:

• Due to inlining, sizeOfSockAddr returns 0. I don't know why. See 6bff610 for my workaround. Without this commit, the test fails.
• Three undefineds still remain. For instance, siz = sizeOf (undefined :: a). We need to check if these do not harm.

[kazu-yamamoto]

Cc: @vdukhovni

[kazu-yamamoto]

Relating to #412

[vdukhovni]

I like StrictData, but I am very much not a fan of Strict, especially as a default. Enable it in some specific modules where you can demonstrate meaningful performance improvements, but otherwise I would not like to see it used. I think it is over-rated, and may as often make things slower, or change semantics.

[kazu-yamamoto]

I know a person who like Strict but not StrictData. :-)

My motivation is to make it easier to debug memory (or space) leak. Without these pragmas, I need to suspect everything. For performance, we have a profiling. If performance gets poor, we can try adding lazy patterns with profiling. But for memory leak, we don't have good tools at all.

[vdukhovni]

Is there a space leak in the Network library that motivates these changes? You can find space leaks with cost-centre annotations and tools that report memory use by cost-centre. This is not that difficult.

Many space leaks are taken care of via StrictData. I don't think I can support a default Strict pragma, but the changes to avoid undefined where it is reasonably natural to do so are fine regardless.

[kazu-yamamoto]

I don't know that network is actually leaking. But I know that all libraries can leak with lazy evaluation.

Even forever leaked in the past: https://gitlab.haskell.org/ghc/ghc/issues/12804. I don't want to spend my time for such things.

I realized that I can split this PR into three:

1. removing undefined as much as possible
2. introducing StrictData
3. introducing Strict

I guess that @vdukhovni agrees with 1) and 2).

What do other guys think? Please speak up.

[kazu-yamamoto]

I'm closing this in favor of #457.