Hi Waldek, also Happy New Year to you.
> But the code fails to compile as Aldor. > #include "aldor" > > NonAssociativeSemiRng : Category == with; > SemiGroup : Category == with; > > BiModule(R : SemiRng, S : SemiRng) : Category == with; > -- BiModule(R : SemiGroup, S : SemiGroup) : Category == with; > > SemiRng : Category == Join(NonAssociativeSemiRng, BiModule(%, %), SemiGroup) > -- SemiRng() : Category == Join(NonAssociativeSemiRng, SemiGroup) Nice example. And bad for Aldor. You have, in fact, already given a workaround to the compilation problem in your commented version. One needs an intermediate category that has enough properties. You called it SemiGroup. A better name would probably have been SemiRngAux or so. Looks like a weakness of Aldor. ... but I have not yet tested Peter's new branch. > Anyway, constructs like this appear in FriCAS algebra and to build > interface we need a way to compile them. Yes. And even if Peter's branch works on your example or even to compile libaxiom.al without any changes in the algebra code, I somehow have the feeling that I can also make it work with the current master branch of Aldor. There is some wizardry that injects such "intermediate categories". All of this is still some mystery for me even though I'm maintaining the fricas-aldor connection. For libaxiom.al, the algebra categories are grouped into cliques that have to be compiled in one file with aldor. These cliques are not identical with what fricas takes in one chunk. In particular there is a big clique mainly coming from aggcat.spad but containing other categories/domains and missing some. To break the cliques even more, initlist.as is used and has to be finetuned by hand whenever the algebra code changes in some incompatible way (as for example the step from Ring to Join(SemiRng,AbelianMonoid). I have suspicion that this time, I also have to play with initlist.as, however, now I need to understand better how exactly the "breaking cliques" works. In fact, meanwhile I've found out that the actual problematic change was by these lines of the patch: https://github.com/fricas/fricas/commit/3a1a01ee22ac98ba481431aa7fbee4641ebf0d02#diff-a006d10d2df53763e50b5e289aaf017dR1671 - Join(IndexedAggregate(Integer, S), Collection(S)) with + Join(IndexedAggregate(Integer, S), Collection(S), + Eltable(UniversalSegment Integer, %)) with That triggered another cliques computation than without this patch. Your example is quite helpful, because adding "with" in your SemiRing definition leads to a similar error message than the one I get from the failing libaxiom.al compilation. I should probably treat "Eltable" in a special way in gendepap.lsp so that UniversalSegment will not be in the clique A1AGG (as is the case when the above patch is not applied). Let's see whether that will resolve the problem. Still, I'm curious whether Peter's aldor branch also solves the problem. In that case we can make the compilation process of libaxiom.al quite a bit simpler 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
