>> When you are going to program Foo, you are not interested in the >> exact category of R. All you need is certain properties that R must >> have. In >> >> Foo(R: CatOfR, S: Join(Monoid, CatOfR)): ... >> >> CatOfR is actually the wrong name. I should better have chosen >> "FoosRequirementForR". The actual category is really not interesting. > > I agree. The interesting situation is more like this: > > Bar(R: Ring, S: CatOfR): ... > > Here I mean that I require S to be from the *same category* as R. > Because R can belong to many other categories besides Ring this is not > quite the same thing as saying > > Bar(R: Ring, S: Ring): ...
I agree with this observation, but I still would like to see a concrete example where the situation Bar(R: Ring, S: CatOf(R)): ... is really necessary. All I can think of for this abstract setting is that knowing that S belongs to exactly the same category as R means that if in Bar there is something like if R has Monoid then SomeCode; then in SomeCode the compiler would not complain if you write s: S := s1 * s2; where s1 and s2 are of type S. I don't consider that a really big advantage, since I could easily have written if R has Monoid and S has Monoid then SomeCode; in order to make everything totally clear in SomeCode. (And I would even prefer this explicit "and S has Monoid".) >> All that Foo cares about is that its parameter has to fulfil a >> certain set of properties which is encoded in the type of the >> parameter specification. I hope I could make that now clear >> enough. >> > > I think what you wrote is clear. You seem to be saying that you do not > think that constructions like 'Bar' are needed in Spad. I am making > the opposite claim. OK. Nothing is bad with opposite opinions, the only problem I have is that I cannot give an example that the 'Bar' construction with CatOf(R) is not needed. That is why I like *you* to give a concrete example (not an abstract one) to support your claim. >> I only heard Waldek saying that SubsetCategory causes 30% of all >> the compile time. > I would like to understand better this claim of "30% of all compile > time". True. But in the end, that is not my main point why I would like to remove SubsetCategory. >> There should be a better implementation of the concepts >> SubsetCategory and SubDomain anyway. I think they are better >> started from scratch if someone sees need for having them. My >> experience with Aldor where these concepts do not exist, is, that >> I never felt the need to reintroduce them. Just let's take a pragmatic >> approach here and have faster compile time now. >> > > I would like a faster compile time, but I do not want to compromise on > the power of the Spad language. As much as I admire your programming > skills in Aldor, I do not think that observations like "My experience > with Aldor where these concepts do not exist, is, that I never felt > the need to reintroduce them." is sufficient justification for > removing features from Spad. Of course that is not a proof. I just lobby for the removal of SubsetCategory. If Waldek finally accepts my patch, fine, if not then that doesn't hurt me so much either. I will have learned something about the internals of FriCAS by then. > I would much prefer that we have some > theory and a model for Spad for which we can (at least in principle) > prove that it provides at least the generality that is necessary to > express a very large part of modern mathematics. As you know, I have > frequently promoted the idea that mathematical category theory > provides such a model. And it turns out that the concept of SubDomain > is a very critical part of such a model. Can you somehow turn your ideas into code? Suppose you have a perfect SPAD (call it SPAD-CAT). How would a polynomial domain in infinitely many variables over some coefficient ring look like. Make it concrete. Of course it will not compile since SPAD is not yet as categorical as you would like. But maybe from your code one sees how SPAD should develop. I don't know whether a polynomial domain is sufficiently complex enough to show the advantage of what you have in mind, but I guess doing it with infinitely many variables might involve some Limit construction. Best regards Ralf --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
