[Haskell-cafe] Laziness question

[Stefan Holdermans]

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