The Revenge of Finalizers

[Alastair Reid]

>> Worse though, I don't even know what semantic framework to use to
>> reason about it if we want to be sure the code will work in the
>> presence of strictness analyzers, eager evaluation, parallel
>> evaluation, fully-lazy evaluation, etc.  Operational reasoning and
>> reasoning by example struggle with such a task.

> However the main assumption that is being made by
> the code I gave is that the thunks containing the unsafePerformIO's
> do not get multiply evaluated.  I think this is a reasonable
> assumption to make.  I am not scared by any of the buzzwords you
> give.  

The essence of all those is that they have been implemented for
Haskell and that they either change evaluation order or increase or
decrease the number of times expressions are evaluated.

Most of them have non-local effects: by analyzing how a function is
written, we can decide to treat the argument differently.  The
compiler can do this because the typesystem tells it the code is pure.
Uses of unsafePerformIO may result in the typesystem saying something
is pure when it is not but in those cases, the blame lies with the
person who used unsafePerformIO for writing the code (that's part of
the spec of unsafePerformIO).

--
Alastair