> The concrete use case was to replace the 188 declarations of coerce by a > handful of declarations of CoercibleTo in the SPAD library.
Maybe you should also read Doye's thesis. As far as I remember, he also says something about how the autocoercion should work. (I somehow refer to what Waldek said about not producing needless loops in the coercion graph.) There is a whole theory behind coercions. Just adding some here and there is not right (in my opinion). > I think that this > would make the library more user-friendly, and could be a first step towards > removing i-coerce and i-coerfn. > But I hesitate to write > > UnivariatePolynomial(var, R) == with Join(CoercibleTo SUP R, > CoercibleTo Polynomial R, > CoercibleTo DMP([var], R), > CoercibleTo MPOLY([var], R) ...) > > This doesn't look right. Doesn't seem to look right. But how else would you want to export coerce: % -> X for any of the replacements for X from above? They must statically be given at compile time or (if "extend" where available) could be added later (but also at compile time). Ralf ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
