I would just like to point out that the author seems to be confusing Pure-Functional-Lazy with just Functional.
Indeed. The problem with many of his earlier examples isn't using closures, it's mixing laziness with side effects.
Some of his other implicit assumptions seem dubious as well. For example, in the printf formatting example, he refers to "optimizations as simple as common-subexpression elimination", but again, if your subexpression has side effects, eliminating the duplicate isn't an optimization, because it explicitly changes the behaviour.
In any case, his basic premise is flawed. If it's really true that "the slightest implicit imperative effect erases all the benefits of purity" then we'd better abandon Haskell, because even programmers of the grandfather of lazy functional languages occasionally sneak outside for an unsafePerformIO while no-one's looking.
Indeed. The problem with many of his earlier examples isn't using closures, it's mixing laziness with side effects.
Some of his other implicit assumptions seem dubious as well. For example, in the printf formatting example, he refers to "optimizations as simple as common-subexpression elimination", but again, if your subexpression has side effects, eliminating the duplicate isn't an optimization, because it explicitly changes the behaviour.
In any case, his basic premise is flawed. If it's really true that "the slightest implicit imperative effect erases all the benefits of purity" then we'd better abandon Haskell, because even programmers of the grandfather of lazy functional languages occasionally sneak outside for an unsafePerformIO while no-one's looking.