Strictness annotations on type parameters

Simon Peyton-Jones simonpj at
Wed Dec 7 03:58:57 EST 2005

It's not at all easy in general. Suppose we have

	f :: [!a] -> [a]
	f xs = xs

Does f run down the list, behind the scenes, evaluating each element?
That could be expensive.  Would it make any difference if we wrote f ::
[!a] -> [a],  or f :: [a] -> [!a]?  Or does the type mean that f
*requires* a list with *already-evaluated* elements?  

It's hard to avoid the feeling that one ought to be able to say
something useful about strictness in the types but it's swampy
territory, and hard to get right.

Meanwhile, you can easily define your own writeIORef:

	strictWriteIORef r x = x `seq` writeIORef r x

No need to sprinkle seq's everywhere!


| -----Original Message-----
| From: glasgow-haskell-users-bounces at
| bounces at] On Behalf Of Mario Blazevic
| Sent: 06 December 2005 21:06
| To: glasgow-haskell-users at
| Subject: Strictness annotations on type parameters
|     I spent several days last week trying to track a cause of a 100%
| slowdown after some trivial changes I made. The profiler didn't show
| slowdown, presumably because it was dependent on optimizations, so I
| to revert to tweak-run-measure cycle.
|     It turned out the slowdown was caused by some unevaluated thunks
| that were kept around in long-lived IORefs. This is not the first time
| was bitten by too laziness, either. What made things worse this time
| that there is no way do declare the following:
| data Label = LabelRef {labelId:: !Unique,
|                        reference:: (IORef !LabelState), -- illegal
|                        origin:: Maybe !Label}           -- illegal
|     No container data type can be annotated as strict. That means I
| to pepper my code with explicit evaluations to HNF before every
| writeIORef (reference label):
| newState `seq` writeIORef (reference label) newState
|     What is the reason for this restriction on where strictness
| annotations can appear? Is it purely an implementation problem or is
| there a reason emanating from Haskell design? If former, how hard
| it be to fix?
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list