That’s what this pull request <https://github.com/elm-lang/core/pull/213>
would have achieved.
​

2016-08-01 20:56 GMT+02:00 Mark Hamburg <[email protected]>:

> 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.
>

-- 
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.

Reply via email to