>But just because they call it `lazy' doesn't mean that it really is
>the essence of laziness. I prefer to use the more neutral name `lifted
>lambda calculus' for their calculus.
I disagree. In the simplest case (just lambdas, variables and applications,
i.e. no explicit constructors), it is *
Gerald Ostheimer notes that in Abramsky and Ong's lazy lambda calculus
that (\x -> bottom) differs from bottom. That's correct.
But just because they call it `lazy' doesn't mean that it really is
the essence of laziness. I prefer to use the more neutral name `lifted
lambda calculus' for their
> I thought this inequality was one of the distinguishing characteristics of
> lazy functional programming relative to the standard lambda-calculus. To
> quote from Abramsky's contribution to "Research Topics in Functional
> Programming", Addison-Wesley 1990:
>
>Let O == (\x.xx)(\x.xx) be t
I have been following this discussion with interest and I'd like
some clarification.
Wadler writes:
> But just because they call it `lazy' doesn't mean that it really is
> the essence of laziness.
What is really been called `lazy' and how is the `essence of
laziness' defined?
Also, forgive my
> So, as Lennart says, if we allow constructors to be strict in functions
> then we have to change the semantics to distinguish _|_ from (\x -> _|_).
> I, for one, am deeply reluctant to do so; I certainly have no good handle on
> the consequences of doing so. Does anyone else?
I thought this i
(This message assumes we head for the strictness-annotation-on-constructor-arg
solution. I'll respond to Phil's comments in my next msg.)
The problem with polymorphic strictness
~~~
John asks what the problem is with strict constructor args. As Lennart and
K
