Just define your own equality operator?
Eg in Haskell, whether things can be compared for equality depends on their representation. (Eg church encoded datatypes do not lent themselves to the built-in derivation of the == operator.)
Re:Functional Programming Jargon
by wereHamster on Monday July 25, 2016 @01:29AM
(#12156661)
If you can't use the builtin `==` operator, you can throw away much of the builtin functionality. The runtime uses `==` in far too many places without ability to provide your own comparator. You want to use your own types as keys in a `Map` or `WeakMap`? Yeah, not going to work.
> Just define your own equality operator?
Have fun doing that in JavaScript. Have fun making objects/hashtables use your custom equality operator when comparing field names. Have fun making sure that every single part of your program respects the notion of equality defined by your custom equality operator.
> Eg in Haskell, whether things can be compared for equality depends on their representation.
In any higher-order langauge, that's a feature, not a bug.
Not knowing anything about this, is the end effect the same?
The effect is that, if you want to reason about JavaScript programs, you can't carry out your reasoning in JavaScript itself, but rather have to use an external metalanguage - ideally something like Hoare logic, but, realistically, usually an informal, insufficiently understood, even insufficiently defined language, like English.
OTOH, a Haskeller can reason about Haskell programs by just evaluating Haskell expressions.
Remember that functions are mappings from values from a domain, into values from a codomain. A language whose treatment of compound values is as feeble as JavaScript's can't possibly constitute the right foundation for doing functional programming.