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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to