4 ms·

I'm also in the interested-onlooker camp, but I think this is an example of a variable denoting a computation rather than a value. It's a Haskell version of an

I'm also in the interested-onlooker camp, but I think this is an example of a variable denoting a computation rather than a value. It's a Haskell version of an exercise in SICP: > p = p > if True then "I'm the value of this expression" else p I would love it if someone would help me phrase this more precisely: the variable p doesn't really have a value, in the sense that evaluating it fully will never finish; it's bottom, the non-terminating computation.

ScottBurson 15y ago
Right. To me, and again I'm not an expert on semantics, but to me, bottom isn't a value in the value domain of the language; it's a meta-value, if you will, a value in the semantics but not in the language. And what it represents is precisely the absence of any value in the value domain of the language. After all, you can't in the language compare two "bottom values" to see if they're equal; there's not even a notion of equality. So the way I would want to put it is that bottom is a notion that we use in modelling the semantics of languages (and I've used it in modelling strict languages too; the value returned by a function when it throws an exception is modelled as bottom), but it's not a value in the language. This contradicts the author's entire argument that the Haskell type system doesn't permit the definition of recursive types. I'd have to learn a lot more to be able to make this argument with any authority. But that's my intuition.