On 03/26/2015 04:25 AM, Waldek Hebisch wrote: > It makes sense to remove implementation of 'map' from > 'ExpressionFunctions2' in non-Ring case,
Yes. Removal of bug is always good. Anyway, it's well known that I don't like Expression(X). Yes, I see its usefulness in some cases, in particular when it represents a tower of field extensions as a rational function over kernels. But, it's hard to explain to a user, what the X in the argument actually is and for why it is useful to have such a parameter. For someone who uses FriCAS, it would probably be better to simply see Expression (no arguments). A domain with argument might be useful internally (for library writers), but in general I don't see usefulness for the ordinary user. For library developers, however, I think, Expression(R) is overloaded. Looking at its implementation reveals that it doesn't have just one representation. There is Fraction(MP) if R has IntegralDomain MP if R has Ring (but not IntegralDomain) FreeAbelianGroup K if R has AbelianMonoid K otherwise K ==> Kernel % MP ==> SparseMultivariatePolynomial(R, K) So, Expression(R) is, in fact, four domains put under one roof. I haven't looked much into the details, but just from that Rep stuff, it would probably make sense to untangle these different use cases (representations) into different domains with clear specification (and perhaps documented use cases) and then write Expression(R) simply as a wrapper domain for them (if that is still interesting). In fact, even though I came up with Expression List Integer, I fail to see where it would be useful. 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.
