[elm-discuss] Re: Function equality again

[Mark Hamburg]

Okay. I'm shutting up here and just tacking this onto
https://github.com/elm-lang/elm-compiler/issues/1145.

On Tue, Oct 25, 2016 at 4:15 PM, Mark Hamburg  wrote:

> Here is a very simple failure case that shows that comparing tasks isn't
> necessarily safe (though it does succeed if I create two success tasks):
>
> import Html exposing (..)
>
> import Http
>
> task1 = Http.getString "http://somewhere;
>
> task2 = Http.getString "http://somewhere;
>
> main = text <| if task1 == task2 then "Match" else "No match"
>
>
> What in this was supposed to clue me in that it might throw a runtime
> exception other than the use of ==?
>
> Mark
>
> On Tue, Oct 25, 2016 at 3:18 PM, Mark Hamburg 
> wrote:
>
>> I just thought of another example where the ability to test function
>> equality matters:
>>
>> Picking up on a discussion on elm-dev regarding the new HTTP rate
>> limiting logic, I thought about moving my case away from using rate limit
>> and instead just creating the model code to manage buffering HTTP requests.
>> This is pretty easy to do with the new Http.Request. (It would also have
>> been straightforward with tasks but might have felt a bit less natural.)
>> But to handle things correctly, I need to test Http.Request for equality.
>> Is that safe to do or does it incorporate a function somewhere — e.g., in a
>> decoder — and hence does comparing it for equality risk a runtime
>> exception? How would I know without looking inside the implementation of
>> Http.Request and potentially everything it references?
>>
>> Mark
>>
>> (*) The specific use case I'm thinking about is a variation of
>> RemoteData.WebData to support setting the desired request as a way to drive
>> it. Thinking about it further, tasks might be even better since they exist
>> at a lower level but similar concerns over equality testing generating
>> runtime exceptions would apply.
>
>
>

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

[elm-discuss] Re: Function equality again

[Mark Hamburg]

Here is a very simple failure case that shows that comparing tasks isn't
necessarily safe (though it does succeed if I create two success tasks):

import Html exposing (..)

import Http

task1 = Http.getString "http://somewhere;

task2 = Http.getString "http://somewhere;

main = text <| if task1 == task2 then "Match" else "No match"


What in this was supposed to clue me in that it might throw a runtime
exception other than the use of ==?

Mark

On Tue, Oct 25, 2016 at 3:18 PM, Mark Hamburg  wrote:

> I just thought of another example where the ability to test function
> equality matters:
>
> Picking up on a discussion on elm-dev regarding the new HTTP rate limiting
> logic, I thought about moving my case away from using rate limit and
> instead just creating the model code to manage buffering HTTP requests.
> This is pretty easy to do with the new Http.Request. (It would also have
> been straightforward with tasks but might have felt a bit less natural.)
> But to handle things correctly, I need to test Http.Request for equality.
> Is that safe to do or does it incorporate a function somewhere — e.g., in a
> decoder — and hence does comparing it for equality risk a runtime
> exception? How would I know without looking inside the implementation of
> Http.Request and potentially everything it references?
>
> Mark
>
> (*) The specific use case I'm thinking about is a variation of
> RemoteData.WebData to support setting the desired request as a way to drive
> it. Thinking about it further, tasks might be even better since they exist
> at a lower level but similar concerns over equality testing generating
> runtime exceptions would apply.

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

Re: [elm-discuss] Re: Function equality again

[Mark Hamburg]

I gather there has been trepidation about implementing an equatable built in 
"type class" akin to the existing "comparable", but I agree that if the plan is 
never to support function comparison, then equatable seems to be necessary if 
Elm is to live up to its "no runtime errors" goal.

As for examples of where this matters, easing functions are an example. Needing 
to keep tagger functions around would be an example. (For example, a web socket 
based request/response system would send the request and then watch the message 
subscription for a matching response and post it back as a message using a 
tagger function much as HTTP-based commands do.) There are a lot of places 
where hanging onto a function in the model is useful and the alternatives are 
convoluted. Note that all of those would likely work fine with reference 
equality and would be even more likely to work fine with one level of reference 
equality checks on the code and the closure values. Most of those cases also 
don't inherently need equality checks, but without compiler support to prevent 
them, such checks can come further up in the model logic possibly in an effort 
to suppress updates that didn't change anything.

Mark

> On Oct 12, 2016, at 1:04 PM, Joey Eremondi  wrote:
> 
> A compile-time error is definitely possible. Haskell has it, but it uses the 
> full power of type classes.
> 
> To catch it at compile time, we'd either need to treat equality like 
> comparable, which sucks for user-defined types, or do something that looks 
> more like Haskell's type classes, with a bunch of automatic deriving. I'd 
> advocate the latter, although I think it could be done in a way that hides 
> most of the typeclassy stuff from the user.
> 
>> On Wed, Oct 12, 2016 at 12:59 PM, Kasey Speakman  
>> wrote:
>> For context for future readers, this has to do with animation easing 
>> functions from another thread. 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, 

[elm-discuss] Re: Function equality again

[Zinggi]

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

[elm-discuss] Re: Function equality again

[James Wilson]

I basically agree - something as basic as using an equality test should not 
have any chance to cause a runtime error in any case; in the case of 
functions it should be based on referential equality, which I think does 
the right thing in any sane case.

On Wednesday, 12 October 2016 17:48:12 UTC+1, 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Function equality again

[Kasey Speakman]

So what's the specific case where you need to verify function reference 
equality?

I suspect that needing this is a symptom of some other problem.

On Wednesday, October 12, 2016 at 11:48:12 AM UTC-5, 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.