Peter Eisentraut <peter_e@gmx.net> writes:
> I propose that you always ensure (preferably at function creation time)
> that each equivalence class is a lattice under the partial order described
> in the previous paragraph.
Er ... weren't you just objecting to metric-based resolution on the
grounds that it'd be unintelligible to users? This has got that
problem ten times worse. In fact, I'm not sure *you* understand it.
> 3) There exists at least one function P in the equivalence class such that
> Q <= P. Consider the set A of all functions in the equivalence class that
> are >= Q. Since the class is a lattice, A has a (unique) greatest lower
> bound. That's the function you call.
I don't think so. The lattice property only says that the set A has a
glb within the equivalence class. AFAICT it doesn't promise that the
glb will be >= Q, so you can't necessarily use the glb as the function
to call. The reason why is that Q isn't necessarily part of the set of
given functions, so it's not necessarily one of the lower bounds that
the lattice property says there is a greatest of.
If that wasn't what you had in mind, then you are confusing a lattice
on the set of *all possible* functions with a lattice over the set of
functions that actually are present ... and it looks to me like
different parts of your argument assume different things.
> An example, say you define foo(int2, float8) and now want to add foo(int8,
> float4), then the system would reject that because of potential ambiguity
If your equivalence set contains just the four functions (abbreviating
in the obvious way)f(i2, i2)f(i2, f8)f(i8, f4)f(f8, f8)
then each two-element subset of this set has a unique glb and lub within
the set, which makes it a lattice if I'm reading my dusty old abstract
algebra textbook correctly. There may be a property that makes things
work the way you suggest but it's not the lattice property.
A more general comment is that mathematical purity is only one of the
considerations here, and not necessarily even one of the most important
considerations ;-)
regards, tom lane
