Waldek Hebisch <hebi...@math.uni.wroc.pl> writes: | I wrote: | > | > Gabriel Dos Reis wrote: | > > | > > Waldek Hebisch <hebi...@math.uni.wroc.pl> writes: | <snip> | > > | | > > | new : (NonNegativeInteger, S) -> % | > > | | > > | So the first argument to 'new' must be 'NonNegativeInteger' and the | > > | second must be '%'. | > > | > > 1. new, expects its second *argument* to be of type %. It does not | > > require that there be no implicit coercion between the argument | > > as lexically written in the source code, and the actual code | > > generated for that argument. If one thinks that the mere presence of | > > the parameter "Rep" indicates that is the representation domain, | > > therefore the implicit coercion from Rep to % is OK, then 0@Rep is | > > a good viable candidate. | > > | > > 2. Fortunately, in this case, 0@% is also defined explicitly to be | > > 0$Rep, but there is no requirement that be the case. And when | > > it is not, we get a problem. | > | > Actually 13.6 says that '%' take precedence over 'Rep', so this one | > is excluded. | > | > > 3. ModMonic(R,Rep) satisfies UnivariatePolynomialCategory(R), so that | > > means that there is alsoanother implicit coercion that turns | > > 0@R into a legitimate value of type %. | > > | > > 4. Similar reasoning holds for 0@Integer because % satisfies Ring, | > > and there is an implicit coercion from Integer to any domain that | > > satisfies Ring. | > > | > > 5. Since NonNegativeInteger is a subdomain of Integer, it also | > > provides an implicit coercion. | > > | > > So, in fact if one thinks that the mere presense of the parameter Rep is | > > sufficient to indicate representation domain and therefore implicit | > > coercions, then we have a legitimate case of ambiguity. | > | > OK, if you think about exact operations used to produce 0, then | > there is really ambiguity. However, IMO coercions are supposed | > to be homomorphims, so each of ways should lead to 0 in '%'. | > | | A little correction: when checking if selected modemap | is applicable compiler tries to coerce obtained result | to requested type. AFAICS compiler only will succeed | coercing '%' to '%' and 'Rep' to '%'. I am not sure if | hacks to prefer '%' over 'Rep' work in this case. If yes | then there is no ambiguity in choice of operations. | If no, maybe we should fix compiler to choose '%' (given that | this preference is documented).
See my comment in a message I just sent. I do not know whether that hack works for FriCAS all the time. I know it did not for OpenAxiom and I got frustrated -- simple case is compiler error, less simple is when one gets a runtime infinite recursion without knowing where to search. This is part of what prompted me to look closer at function selection in general, and that of constants in particular. | Also, if chooses representation which has 0 different than | 0 in %, then it is probably better not to specify Rep at | all. Did you consider suppresing the implicit conversion from Rep to % and vice versa? -- Gaby ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
