Limiting the value recursion is not enough, of course. You'd have to
limit the type recursion as well.
-- Lennart
On Jan 24, 2007, at 10:41 , Robert Dockins wrote:
On Jan 24, 2007, at 8:27 AM, Lennart Augustsson wrote:
Well, I think fix destroys parametricity too, and it would be
On Jan 24, 2007, at 8:27 AM, Lennart Augustsson wrote:
Well, I think fix destroys parametricity too, and it would be better
to get rid of fix. But I'm not proposing to do that for Haskell,
because I don't have a viable proposal to do so. (But I think the
proposal would be along the same lines
Lennart Augustsson wrote:
Well, I think fix destroys parametricity too, and it would be better
to get rid of fix. But I'm not proposing to do that for Haskell,
because I don't have a viable proposal to do so. (But I think the
proposal would be along the same lines as the seq one; provide fix
in
Well, I think fix destroys parametricity too, and it would be better
to get rid of fix. But I'm not proposing to do that for Haskell,
because I don't have a viable proposal to do so. (But I think the
proposal would be along the same lines as the seq one; provide fix
in a type class so we can kee
Janis Voigtlaender wrote:
Janis Voigtlaender wrote:
Lennart Augustsson wrote:
There is a good reason seq cannot be defined for functions in
the pure lambda calculus... It doesn't belong there. :)
How about the same argument for general recursion? As in: There is a
good reason (typability
Janis Voigtlaender wrote:
Lennart Augustsson wrote:
There is a good reason seq cannot be defined for functions in
the pure lambda calculus... It doesn't belong there. :)
How about the same argument for general recursion? As in: There is a
good reason (typability) that fixpoint combinators ca
Lennart Augustsson wrote:
I don't think disallowing seq for functions makes them any more
second class than not allow == for functions. I'm willing to
sacrifice seq on functions to get parametricity back.
The underlying assumption that having seq makes us lose parametricity is
a (widely spread
