I think I'm going to revise my stance on how this issue should be handled. I am now gong to argue that function equality should be handled via object identity — i.e., two closures constructed at different times are necessarily unequal.
What this breaks is referential transparency and more specifically it means that compiler optimizations could change the results computed by programs. That last point seems disturbing, but let's consider what this really means. The issue of concern is that the compiler could decide to lift a closure construction and thereby make more things that weren't equal to each other in the un-optimized code now equal to each other. I think it would be reasonable to say "don't use functions as a way to cause things to be unequal because if you do that may not survive compiler optimization." This seems at least as reasonable as saying "don't compare functions or structures containing functions because the program might throw a runtime exception if you do". If it really seems of concern, then write a non-fatal message to the console log whenever comparing functions that aren't equal via object identity and aren't obviously non-equal because they say reference different pieces of code for their definitions (though of course even that raises questions about what it means for functions to be equal). But my basic argument now is that it seems better to fail at referential transparency than to throw runtime errors. Mark -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
