Good morning Ralf,
On Thu, Feb 22, 2024 at 7:56 AM Ralf Hemmecke <[email protected]> wrote: > On 2/21/24 21:23, Hill Strong wrote: > > 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. > > See https://fricas.github.io/book.pdf page 15: "Domains Belong to > Categories by Assertion", > > You may wish for something else, but that's the way it is in FriCAS (and > Aldor). > I have no issue with this. However, whether a particular assertion is named or not, it should not matter once you have made the assertion. Unless, each assertion generates something new. If you were to say Join(CatA, CatB) in one place and then do so again in another place and each of these assertions is different from each other then I would not have a problem with it also being different from a named assertion CatAB. BUt, as far as I can tell, using the former in multiple places means the same semantically. Hence the question as to why if would be different from the named variety? > > > >> 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? > > Dom is of CatA and of CatB but not of CatAB. FooC requires its argument > to be of CatAB, but Dom is not of that type, so FooC(Dom) cannot be > compiled. > But why is the distinction being made as they are the same thing? The only difference is the that one uses a name and the other doesn't. > > > 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. > > You wish something else. That's fine. But the SPAD language implements > "a domain only belongs to a (named) category if that category is > explicitly included when the domain is defined". > >From my perspective then this is wrong on the part of the SPAD implementation unless every anonymous usage is to be considered different even though they have identical forms. The point is subtle but highly important for consistency. > There are ideas of "post facto extensions" in Aldor > http://www.aldor.org/docs/HTML/chap10.html or look into the Aldor User > Guide (http://www.aldor.org/docs/aldorug.pdf) that would make life a bit > easier. Unfortunately, SPAD does not (yet) implement this idea. > And it would still be the same. Domains belong to categories by assertion. > As I said above, there is no issue here. The problem from my perspective is that the assertion is identical irrespective of whether the assertion is named or anonymous. > > >> 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. > > You can see it that way. However, the current behaviour *is* documented > and the compiler behaves accordingly. > >From your perspective, it may appear to be true. But from my perspective as someone who has and does design languages, it is not. We can back and forth this all day and not come to any form of agreement. So be it. At least, I am getting some very useful information from these discussions, so thank you. > > > 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. > > If you can help to make FriCAS better, you are welcome. > My goal at the moment is to redesign the language to be more consistent and more shall we say [modern] bringing it up to the mid-70's to mid-80's. The reason I am asking these questions is that in making the language more consistent, these things are being found in the FriCAS code base. SPAD itself will be essentially dispensed with. There are certain aspects of the language that are amenable to using LR parsers and other aspects where the current Pratt parser is better suited. I have in the past incorporated dynamic changes of Lexers into LR parsers and now I am working on incorporating Pratt parsing into LR parsing, which is an interesting project in and of itself. It hasn't been done in this particular way before (at least not in the literature that I have been reading) but it shouldn't be too problematic as it is a variation on how error handling is at times incorporated into LR parsers. > As for the learing curve... I usually point someone who wants to learn > SPAD to reading the Aldor user guide (AUG). Yes, Aldor is a bit > different from SPAD (I once listed a number of them here > http://wiki.fricas.org/LanguageDifferences), but the AUG much better > defines the language than the FriCAS-book does. > > Ralf > Have a blessed day ahead Hill > > -- > 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/702b534b-dab0-4ccb-a16a-c9c4923976a2%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/CAEnaMTGdH8xBW%3DELDLEXNy%3D3T%3Dg2u1pSYC4uekCDdnEJQE%2BiBQ%40mail.gmail.com.
