| > An identity value, whose virtue is that it is different from other identities, is a legitimate concept which can be treated under functional programming. Of course. But I don't want object identities to be the only values I can manipulate. I like having values like the list [1,2,3]. > Your equality then has to basically test that two Turing computations are equivalent: that the underlying lazy generation procedures themselves are computing the same thing, even if in different ways. Indeed, this means that equality of higher-order values is undecidable. Therefore, don't rely on testing whether higher-order values are equal - you just can't! This is also why laziness by default is such a bad idea. > In that vein, what do you do about structures with cycles and shared structure? In Standard ML, `val rec xs = 1 :: xs` simply doesn't compile. The right-hand side of a `val rec` definition must be a function literal. This guarantees that inductive data types (such as lists and trees) mean the right thing, and that structural recursion on them always terminates. > Equality is not so simple that we can just cover all of its nuances with a blanket rule based on some handwaving principle. I'm not handwaving anything. |