[Haskell-cafe] Laziness question
stefan at vectorfabrics.com
Sun Aug 1 04:53:24 EDT 2010
> I would deeply in favor of renaming seq to unsafeSeq, and introduce a
> type class to reintroduce seq in a disciplined way.
There is a well-documented  trade-off here: Often, calls to seq are introduced late in a developing cycle; typically after you have discovered a space leak and figured out how to resolve it. Then you introduce a call to seq somewhere deep in a call chain. If seq were a class method, you would know have to work your way upward in the call chain to update all type signatures you had written there. Clearly, this is quite tedious. And then, almost just as often, you find out that actually you did not quite figure out how to resolve the space leak, because it's still there. So, you remove your freshly introduced call to seq and, indeed, work your way to the call chain again to remove all now superfluous class constraints from the type signatures. (By the way, this is typically the sort of task, IDEs with refactoring support excel at, but these are unfortunately not ubiquitous for Haskell yet.)
More importantly, the type-class approach is flawed . It assumes that all seq-related constraints can be "read off from type variables", which is in fact not the case.
 Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler. A
history of Haskell: Being lazy with class. In Barbara G. Ryder and
Brent Hailpern, editors, Proceedings of the Third ACM SIGPLAN
History of Programming Languages Conference (HOPL-III), San Diego,
California, USA, 9–10 June 2007, pages 1–55. ACM Press, 2007.
 Daniel Seidel and Janis Voigtländer. Taming selective strictness.
In Stefan Fischer, Erik Maehle, and Rüdiger Reischuk, editors,
INFORMATIK 2009 – Im Focus das Leben, Beiträge der 39. Jahrestagung
der Gesellschaft für Informatik e.V. (GI), 28. September – 2.
Oktober, in Lübeck, volume 154 of Lecture Notes in Informatics,
pages 2916–2930. GI, 2009.
More information about the Haskell-Cafe