First idea: Two functions are the same if their pointers (or closure
pointers) refer to the same value. This is usually a recipe for disaster.
As many people have noted, program transformations made by the compiler can
change the pointers. So the meaning of your program is suddenly dependent
on the particular version of Go, or the particular optimizations you have
enabled. Moving around code can alter a program analysis to make an
optimization (not) trigger as well.
All in all, if you want to avoid subtle errors in your programs, this is a
bad equality definition.
Second idea: Two functions are the same if they are the from a *syntactic*
point of view. In particular functions such as
func f(x, y int) int {
return x + y
}
func g(x, y int) int {
return y + x
}
will not be equal. This is deeply unsatisfactory, as we human beings are
rather good at figuring out that the two functions are actually the same
function with the same semantics. We probably wouldn't accept this as a
valid kind of equality. But it has the advantage it is fairly easy to
compute and it is not troubled as the pointer solution: we can create it
deterministically.
Third idea: functions f and g are equal if
f(x) = g(x) forall inputs x (1)
This is in many ways the right definition, implementation troubles aside.
Whenever you optimize your code, you replace a slow f with a fast g. They
better behave the same on all inputs. Many proofs of programs utilize this
notation as well (it is called extensionality). The idea is that if you
can, externally, prove that the above (1) holds, then surely you can swap f
for g in a program with no change. Proof assistants usually have more
powerful type systems which allows you to write down such a proof for a
given program. However, most programming languages do not. They rely on
some external proof of correctness in its place.
Testing (1) is in general impossible since the space from which the
x-values are drawn might be infinitely large in a way that it cannot be
symbolically contained. For some cases, you may be able to model-check all
inputs, or you may be satisfied with a large number of random trials. The
latter *is* possible in Go fairly easily. See the
https://golang.org/pkg/testing/quick/ package and in particular the
CheckEqual function.
Fourth idea: disallow equality checks on functions.
In many ways, this is the sane solution. While we would like the third idea
above, it is in general not achievable, so we have to opt for a lesser
solution. And since most of those have flaws—one way or the other—we opt
for a non-solution. It isn't that far-fetched: some languages disallow
equality tests on floating point numbers because of their numerical
instability. After a couple of computations, the error-term of your FP
computation might be large enough that you won't compare equal to the
original value. Hence, by disallowing direct equality comparison, you force
people to check for equality by scrutinizing the difference and checking if
it is under some ε-value.
On Wed, Nov 23, 2016 at 2:40 PM T L <tapir....@gmail.com> wrote:
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
