For context for future readers, this has to do with animation easing functions from another thread <https://groups.google.com/d/topic/elm-discuss/bOAHwSnklLc/discussion>. I have not constructed such a library, so I won't comment.
On Wednesday, October 12, 2016 at 2:43:58 PM UTC-5, Zinggi wrote: > > 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.
