<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I am shepherding the Eval class proposal, #29. Very, very briefly, this proposes to bring back<div class=""><br class=""></div><div class="">> class Eval a where</div><div class="">> seq :: a -> b -> b</div><div class=""><br class=""></div><div class="">The author of the proposal cites some motivation, but a recurring theme in the discussion is that this is just the first step toward some ill-defined promised land. The author himself admits he’s not quite sure what the promised land holds, other than safety under eta-expansion, along with a restoration of parametricity.</div><div class=""><br class=""></div><div class="">The proposal includes a new extension, on by default, -XUniversalEval, that adds Eval constraints in many places. Even with -XUniversalEval, however, this extension is not fully backward compatible, in corner cases (seq’ing in a class method; polymorphic recursion, possibly higher-rank types.</div><div class=""><br class=""></div><div class="">I move to reject this proposal. The author (along with a few others) argues that this brings some nice theoretical properties to Haskell. I agree here. But the cost doesn’t seem to be worth the benefit, especially considering that this may be the first step toward some ill-specified goal. In short, while I might be happy enough with the language proposed here, I don’t relish the idea of getting from where we are to that language, and I don’t think the gain is worth the pain.</div><div class=""><br class=""></div><div class="">You can see the PR here: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/27" class="">https://github.com/ghc-proposals/ghc-proposals/pull/27</a></div><div class=""><br class=""></div><div class="">Richard</div></body></html>