Interesting. How does non-strict evaluation match?

Because in hardware you can have undefined states (bottom) and it’s fine as long as you don’t observe the undefined state (pattern match on bottom). The only difference is pattern matching on Unit, which is represented by a zero-width bus in hardware. Beyond that, non-termination “contaminates” a value just like undefinedness “contaminates” a circuit.

What is the small difference?

Zero-bit busses cannot have an indeterminate value in hardware. However, zero-bit values (Unit) can have indeterminate value in software.

If you have the circuit

f :: () -> Int

f () = 3

Vs

g :: () -> Int

g _ = 3

Are the exact same thing in hardware but different in software.

“f undefined” is undefined in software but “g undefined” is not. Neither is undefined in hardware.

This distinction comes up very rarely. Only if you have a parametric circuit that sometimes takes zero-bit inputs (I.e. if the input is unused in some instantiations).

IIUC, this is actually a general deficiency in the type system for variable-width tuples. Consider:

  f1 :: (Bit,()) -> Int
  f1 (0,()) = 3
  f1 (1,()) = 3
  -- f1 (0,undefined) is undefined
  f2 :: (Bit,(Bit,())) -> Int
  -- and so on. Conversely
  g2 :: Bit -> Bit -> Int
  g1 :: Bit -> Int
  g0 :: Int
  -- doesn't have this problem but also doesn't work well for busses.
  -- The 'obvious' approach
  h3 :: (Bit,Bit,Bit) -> Int
  h2 :: (Bit,Bit) -> Int
  h1 :: (Bit) -> Int
  h0 :: () -> Int
  -- doesn't work generically; (Bit) isn't a tuple at all,
  -- and n-element tuples are totally unrelated to m(!=n)-element tuples
  -- (they're literally declared as:
  data (a,b) = (a,b)
  data (a,b,c) = (a,b,c)
  -- in module GHC.Tuple)

You can actually fix this by (ab)using types of kind `TYPE 'UnliftedRep` and unboxed tuples (type `(# Car, Cdr #)`, value `(# b7, b6543210 #)`), it's just generally not worth the effort.