

The Point of Laziness in Programing Languages - gus_massa
http://existentialtype.wordpress.com/2011/04/24/the-real-point-of-laziness/

======
ScottBurson
_variables in a lazy language range over computations, including the non-
terminating computation, whereas in a strict language they range only over
values_

This is a very interesting comment that I am not sure I believe.

Let me acknowledge up front that I am aware that the author is a Haskell
expert, and I am not anything resembling one. So this comment is definitely
from an interested-onlooker perspective.

Still, from what little I know, it seems to me that variables in Haskell still
range over values, not over computations. For instance, the expression "x ==
y" is not true when x and y are the same computation; it is true when those
computations yield the same value. I understand that operationally, those
values may not be computed until needed for the equality test, and I
understand that the computation of one of them may not terminate; but I still
don't see how that means that the variables range over computations.

What am I missing?

~~~
Periodic
Let's say you have a type that's a value of a typeclass Typeable that has a
function "a -> String" (the real Typeable class has the signature "a ->
TypeRep) which tells you that type of the argument.

Let's now say I define some data type:

    
    
        data Foo = Foo
    

and make it an instance of typeable.

    
    
        instance Typeable Foo where
            typeOf _ = "Foo"
    

Note that the function doesn't actually care what's in it. The following is
all valid:

    
    
        > typeOf (Foo)
        "Foo"
        > typeOf (undefined :: Foo) -- making an bottom value of type Foo
        "Foo"
        > typeOf (let f y = if y then Foo else f y in f False) -- not terminating computation.
        "Foo"
    

All three of these are valid variables. They may be stored as thunk, and only
when you try to extract the value of the thunk do they cause errors. It is
still perfectly valid to pass them around as values and store them.

~~~
ScottBurson
See my reply to happy4crazy. Your examples are interesting, but I still think
that to say that _bottom_ is an element of every Haskell type is to commit a
level confusion. It would be more accurate to simply say that expressions and
variables in Haskell don't always have values. What your examples show is
simply that the language is not strict: an expression can have a value even if
one of its subexpressions does not.

In mathematics, we don't have this notion of a variable with no value, so to
write a formal semantics for Haskell we have to make up this "meta-value"
_bottom_. But it should not be confused with a value in the language, as it is
not one.

Again, this is all my intuition and I'm not an expert. But so far, I don't see
what's wrong with this view.

~~~
Periodic
In comparison to math, I think bottom is very close to the idea of an
undefined value. What is the value of 4/0? What is the derivative of a step
function at 0?

Mathematics often goes out of its way to make sure things aren't undefined by
defining domains that exclude the undefined values. In programming we do the
same thing most of the time.

I think what I missed is that bottom in Haskell is really an exception. It's a
value that doesn't really exist. Trying to force it gives an exception. The
real results of a computation are concrete values, non-termination and
exceptions.

