Good morning Ralf, On Thu, Feb 22, 2024 at 4:49 AM Ralf Hemmecke <[email protected]> wrote:
> [Remove ...] > Suppose there are two categories CatA and CatB and we define > > CatAB: Category == Join(CatA, CatB) > > You know that there is a little difference between > > FooJ(D): Export == Implementation where > D: Join(CatA, CatB) > Export ==> ... > Implementation ==> ... > > and > > FooC(D): Export == Implementation where > D: CatAB > Export ==> ... > Implementation ==> ... > > You say that there is [little] difference. Why is there any difference? In one case you have created a name for the Join, in the other it is anonymous. Yet, the [value] that is the category in both cases should be identical and hence NO difference between either specification. If there is then the system has a major problem that is not explained anywhere. The semantics should be identical. > . > > If we have > > Dom: Join(CatA, CatB) == ... > > then > > FooJ(Dom) is OK, while FooC(Dom) is not. > Again, what difference is there between either case? The underlying category [value] should be the same and defining a domain as you have done and used in either definition should result in an identical code production. If it does not then again there is a serious problem with the semantics and the compiler is going to bite the user and the code developers in strange and very awkward ways. > In that sense the definition of FooJ is more general. > This should not be the case. > Yes, it may make sense to introduce specific categories, like CatAB, > but you then have to go through the whole FriCAS sources and figure out > in which cases you might have to add something like CatAB to the exports > of a certain domain (or category, and maybe even conditionally, i.e. > depending on a domain parameter). That is doable, but sounds a bit > error-prone. I don't even know whether it is easy to check that such a > code modification did not introduce unwanted behaviour, because we might > There should be very very few cases (zero or close to it) where such changes would be different semantically. If there does arise differences then the underlying compiler (boot) is the problem and needs seriously to be fixed. FriCAS has a high enough learning curve as it is, without strange little semantic anomalies coming out and biting you like some yapping little ankle-biting dog at unexpected times. I fully understand that any code base, especially one as old as this, will build up a lot of cruft over its lifetime. But it does need to be dealt with or the code base will become unmaintainable in many ways. Making little ad hoc changes here and there does not garner well for the system's future where you want more people to be interested in and actively use the system. Axiom and FriCAS both deserve better as does all the hard work that has been put into each by all the people who have been involved over the decades. not yet have a test included for such circumstance. > > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/a37b415c-7eb1-4cb6-8b37-f84f87f9bf5a%40hemmecke.org > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAEnaMTFv3SHUk52krMfx4z7%3DRP9ZnuPmAaqJJZyL9KBmSpAjGQ%40mail.gmail.com.
