Skip to content

Semantics of top-level strict constructor field bindings

Top level strict bindings are not allowed because it would not be obvious when the computation should happen: either at compile time or when the binding is first used or something else. This is why issues like #17521 are still open and we currently get errors like this:

!x = product [1..100]
Top2.hs:2:1: error:
    Top-level strict bindings aren't allowed: !x = product [1 .. 100]
  |
2 | !x = product [1..100]
  | ^^^^^^^^^^^^^^^^^^^^^

However, there seems to be an loophole with strict constructor fields:

data A a = A !a
A x = A (product [1..100])

This compiles without issues and produces the same code as the lazy field equivalent:

data A a = A a
A x = A (product [1..100])

Is this behavior desired or should we issue an error or warning in the strict field case just like we do for direct top-level strict bindings?

Edited by Jaro Reinders
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information