GHC's strictness analysis can be confusing in combination with black boxes

[martijnbastiaan]

Say I've got a black box:

prim :: (A, B, C)
prim = (undefined, undefined, undefined)
{-# OPAQUE prim #-}
{-# ANN prim hasBlackbox #-}

If this output is used:

let 
  (a, b, c) = prim
  d = register a b c

GHC might conclude that, because register is strict in some of its arguments, that the result of the calculation is undefined. This is undesirable, because it will turn perfectly synthesizable code into non-synthesizable junk.

If think we should:

1. Enable -fno-strictness in starter projects
2. Implement a check that makes sure that primitives don't have strictness information attached
3. (After (2), remove (1))

Workaround:

{-# OPTIONS_GHC -fno-strictness #-}

[christiaanb]

The warning won’t help you if the primitive is already elided from the use-site by GHC.

Perhaps we should improve our documentation with regards to these “no-simulation” primitives. Given that custom primitives are an advanced topic, I suspect people only discover them by reading the documentation, so that seems like the right spot to handle this. Turning off strictness analysis for all code in the starter project seems like a ‘baby with the bath water’ kind of thing.