Hi Waldek,
thank you very much in looking deeper.
> bar : (NNI, Z, Z) -> Z
> bar : (Z, NNI, NNI) -> Z
> bar : (NNI, Z, NNI) -> Z
> You could claim that the last two are better match than the
> first one, but it is hard to give reason to prefer one of
> the last two to another. And if we use lexicographic
> order, than suddenly first one is be better than the
> second one. Of course, it is natural to prefer exact
> match to matching a supertype. But partial matches are
> a can of worms...
So, as you know, my approach would be: the compiler should complain and
reject the program since NNI is not Integer, so none of the above bar
matches.
To make that a bit weaker, I could agree that if there is only one
signature visible to the compiler and it has argument type Z, but user
provides NNI, then compiler can select this function. However, I'd like
that the compiler issues a warning (at least optional if that is too
verbose for some people) that the types do not match exactly.
If there are several signatures, one could argue that the compiler is
allowed to choose any. Of course, that should clearly be documented and
programmers should be aware of that issue. But if the compiler can
choose any of those functions, the user must make sure that all
available functions behave in a compatible way. So I could not have
foo(n: N): Z == n
foo(n: Z): Z == n+1
So in other words, allowing the compiler to choose arbitrarily, puts
the burden on the programmer.
I think that burden is reasonable since what else would one expect from
a function that is restricted to a subset of the source domain of a
function with the same name.
But again, coming back to my original problem.
If two signature are around and there is a perfect match, the compiler
should surely choose the function according to the provided type of the
argument and not select the function that works on the supertype.
foo(r: R, n: N): R == r^n
if R has Field then
foo(r: R, n: Z): R ==
n < 0 => inv foo(r, qcoerce(-n)@N)
foo(r, qcoerce(n)@N)
So in this code the function foo in the last too lines refer uniquely to
the unconditional foo in the first line. There should be no question
about this. In other words, the general mechanism in choosing according
to the exact source and target type should have higher priority than any
subtyping relation.
Ralf
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
