
Nicolas, Luke, SH> More importantly, the type-class approach is flawed [...]. It assumes SH> that all seq-related constraints can be "read off from type variables", SH> which is in fact not the case. LP> Could you provide an example (or a specific example or explanation in LP> the paper) of what you mean by this? I don't remember the exact details, but if I remember correctly the main concern of the authors is that by requiring that all function types are in Eval as well, as an older version of the Report did, applications of seq to values of function type are not reflected in types and hence, types do not convey enough information to state some necessary seq-induced extra conditions for parametricity results. Anyway, I guess Janis and Daniel will do a far better job commenting at this. As an aside, or a shameless plug if you will, in a paper presented at this year's PEPM [*], Jurriaan and I mention that having information about uses of seq explicitly available, particularly in types, could be favourable for strictness analysis as well. NP> Actually my point is that if we do not use any polymorphic primitive to NP> implement a family of seq functions then it cannot be flawed. Indeed NP> if you read type classes as a way to implicitly pass and pick functions NP> then it cannot add troubles. NP> Finally maybe we can simply forbidden the forcing of function (as we do NP> with Eq). The few cases where it does matter will rescue to NP> unsafeSeqFunction. I guess not having functions types in Eval would indeed make parametricity less of an issue, but I do not quite agree that the cases in which one may need seq on values of function type are insignificant. Cheers, Stefan [*] Stefan Holdermans and Jurriaan Hage. Making “stricterness” more relevant. In John P. Gallagher and Janis Voigtländer, editors, Proceedings of the 2010 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation, PEPM 2010, Madrid, Spain, January 18–19, 2010, pages 121–130. ACM Press, 2010. http://people.cs.uu.nl/stefan/pubs/holdermans10making.html