I also think that comparing functions should just compare them by reference, this should cover the most common cases.
Another possible solution: What about a compile time error? Is this possible? On Wednesday, 12 October 2016 18:48:12 UTC+2, Mark Hamburg wrote: > > As discussed elsewhere, the runtime exception related to function equality > comparisons is a lurking time bomb for code that is really only addressed > on a multi-developer project by being paranoid both about functions in data > structures and use of the equality operator. Both points of paranoia get in > the way of writing "good" code. There are other arguments around things > like serialization for avoiding using functions in some places, but there > are lots of other places where it is extremely useful to put functions in > data structures. (Imagine writing an effects manager if it couldn't store > functions in its data structures.) > > Full equality tests are, as I understand it, undecidable. That doesn't > mean, however, that some limited analysis can't prove equality in most of > the conditions that matter. In fact, the existing code doesn't always throw > an exception. It only throws an exception if an "allocation identity" test > fails. One could extend this to looking at the "code pointer" and > allocation identity for the closure values and probably get many of the > remaining cases that mattered. It's just a matter of how far one wants to > push when trying to prove or disprove equality and I'm not arguing for a > particular limit here. > > Rather, I think the central issue is around what happens when we give up. > At that point, there are two choices: throw a runtime exception as happens > now or return false. As mentioned above and discussed at further length > elsewhere, the runtime exception leads to paranoid coding. What are the > issues with returning false? The big problem with returning false is that > this means that some compiler optimizations might then change cases that > returned false without the optimizations into cases that returned true and > people become understandably uncomfortable with the possibility that > compiler optimizations could change the meaning of programs. And with that, > I've more or less wanted a "return false" answer but convinced myself that > throwing an exception wasn't unjustified and that maybe what we needed > instead was type system support to avoid the issue. > > But then this morning's discussion of the virtual DOM had me realizing > that runtime optimizations around when the render-diff-patch algorithm gets > run create significant potential for variable program behavior. We embrace > these optimizations even though they introduce non-determinism. Now, its > non-determinism at the level of the physical DOM rather than the values > produced in Elm itself — i.e., runtime v linguistic non-determinism — but > its non-determinism in one of the most fundamental parts about how Elm is > generally used so that distinction seems somewhat arbitrary. > > I think Elm makes the right call on the DOM. Maybe it should log cases > where the DOM logic can recognize that there might be a problem, but I > think this is overall a tradeoff worth making. > > But by the same argument, I think Elm programs would be better if the > runtime exception for function equality comparisons was replaced with a > false result even though it might actually be true. And if it's really > irksome, then it could generate a log statement as well. > > 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.
