> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~----------~----~----~----~------~----~------~--~---
