On Jul 11, 2016, at 4:58 PM, Christopher Anand [g] <[email protected]> wrote: > > >> On Jul 11, 2016, at 7:28 PM, Mark Hamburg <[email protected]> wrote: >> >> On Jul 11, 2016, at 4:23 PM, Mark Hamburg <[email protected]> wrote: >>> >>> A bigger problem is that the requirement that something be equatable or the >>> property that a type is not equatable becomes a hidden part of the >>> interface. >> >> So, here is a more harsh suggestion: if a type can't be locally proven >> equatable, then it is not equatable. >> >> This would break a lot of programs that use equality and inequality, but >> many of those programs are arguably runtime errors waiting to happen. > > Do you have examples of programs which would break and should not break? > > I had assumed the pessimistic rule would be applied, anyway, although I’m > sure I’ve deleted previous posts which would have told me otherwise. :) > > If there are equatable types which could not be proven so, it would be better > to give as an error message that > > “The type you are testing for equality with (==) cannot be proven to be > equatable at this time. If you believe it really is equatable, try > simplifying the involved code.” > > Christopher
I don't have an example immediately available though I could construct one. But the basic rule is: functions and structures that contain functions aren't equatable. So, if something can't be locally proven to be function free, it isn't equatable. This would mean that types imported from other modules would not be eligible for use with == and exported parameterized types would not be equatable because we wouldn't know how the caller was going to use them. It might be nice if there were a way to mark an exported type as equatable, but that leads to type classes which is something Elm is trying to avoid. The net effect of this would probably be to make == essentially useless except for working with primitive types. That's not necessarily a bad thing though it leads to another suggestion: == should only work with comparable types (using the existing type system infrastructure). It would be interesting to know how much existing Elm code would break with that choice and how hard it would be to fix a substantial number of the remaining cases. 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.
