[Haskell-cafe] Re: Laziness question
jv at informatik.uni-bonn.de
Tue Aug 3 10:55:55 EDT 2010
Maybe I should add that, maybe disappointingly, I do not even have a
strong opinion about whether seq should be in Haskell or not, and in
what form. Let me quote the last paragraph of an extended version of our
paper referred to earlier:
> Finally, a natural question is whether or not selective strictness
> should be put under control via the type system in a future version of
> Haskell (or even removed completely). We have deliberately not taken a
> stand on this here. What was important to us is that both the costs and
> benefits of either way should be well understood when making such a
> decision. Maybe the realization that, contrary to popular opinion, a
> relatively simple approach like the one that was present in Haskell
> version 1.3 does not suffice to keep selective strictness in check, and
> that instead something slightly less wieldy, like our type system
> presented here or a similar one, would be needed, will quell the
> recurring calls for "putting seq in a type class" once and for all. Even
> then, while it would mean that our type system does not get adopted in
> practice, we would consider our effort well invested. At least, the
> community would then have made an informed decision, and part of the
> justification would be on record.
That's under the assumption that the requirements we have on a solution are:
1. All Haskell programs that could be written before should still be
implementable, though potentially with a different type.
2. Parametricity results derived from the (new) types should hold, even
if seq is involved.
The Haskell 1.3 approach achieves 1. but not 2.
The approach of an Eval class without a function type instance achieves
2. but not 1.
Lennart suggested that the programs one loses that (latter) way might be
few in practice. I have no idea whether that is true, but it might well be.
But it is actually new to me that proponents of putting seq in a type
class admit that they can only do so and achieve 2. by accepting to give
up 1. In the past, also in the "Being lazy with class" paper, the
impression was given that the controversial issue about the Haskell 1.3
solution were just its practicality in terms of how cumbersome or not
the additional typing artifacts become. While it was simply supposed
that at least that solution achieves both 1. and 2. It does not.
Jun.-Prof. Dr. Janis Voigtländer
mailto:jv at iai.uni-bonn.de
More information about the Haskell-Cafe