Ralf Hemmecke wrote: > > > The point of change is every current user of AbelianMonoidRing > > optionally gets new functionality: if user proviedes a Ring as an > > argument that the category should be as before. If user supplies it > > with a semiring, then one gets new behaviour. > > Can you give an illustrating use case where your generalization is > important? What did you have in mind when you made this generalization? > > > In other words, if we introduce a new category we should at the same > > time remove AbelianMonoidRing and replace all uses of > > AbelianMonoidRing by the new category. > > Of course, we could do that, but I find AbelianMonoidRing a rather > important category that deserves its own existence. Yes, it is always > questionable how to construct a good category hierarchy. In my opinion, > we should simply take established mathematical structures and try to map > them into the FriCAS category hierarchy. We anyway have already a > problem that usually mathematical concepts do not always map well into a > computational (i.e. constructive) context. > > >>> There is also problem of code stablity: we will from time to > >>> time generalize various constructors. > >> > >> Yes that's a problem and should be done with great care. I'm not > >> totally against such generalisations. But in the case of > >> AbelianMonoidRing, I'd like to keep it a Ring. > > > > This is not an option. Either AbelianMonoidRing will surrend its > > ambition of always beeing a Ring or it will be exterminated. > > I don't really understand what you want to say by this. As I said. I > want AbelianMonoidRing to always be a Ring.
The point is that I want generic constructors which given a Ring will give me a Ring, given SemiRing will give me a SemiRing, etc... To unconditionally get Ring as result we need Ring as argument. Once the argument type is restricted to Ring this restriction will propagate up the category hierarchy meaning that restricted constructor is useless for building generic ones. Of course one can think of cases where generalization really is not needed. However, if we allow restricted constructor to co-exist with generic one then there will be confusion which one to use and there is substantial risk that we will end up with two parallel category hierarchies, one generic and one restricted. We avoid those risk by providing only generic version. BTW: Earlier commit generalized 'IndexedDirectProductObject'. Conseqently 'IndexedDirectProductAbelianMonoid' (and few others) was no longer needed and was removed. > > As I wrote in the message about products I think that more exports > > should be conditional. > > Waldek, can you give a pointer? I don't really know what you are > referring to. http://groups.google.com/group/fricas-devel/browse_thread/thread/208afe777904abfc?hl=en# I will be for few days without e-mail access, so probably my next message will be in next week. -- Waldek Hebisch [email protected] -- 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.
