On 30 May 2014 03:35, Ralf Hemmecke <r...@hemmecke.org> wrote: >... We can have > > just PositiveInteger as argument type. > http://hemmecke.de/fricas/html/PrimeField.html >
Yes. Its "signature" is: PrimeField(p : PositiveInteger) : Join(FiniteFieldCategory, FiniteAlgebraicExtensionField(%), ConvertibleTo(Integer)) or PrimeField: PositiveInteger -> Join(FiniteFieldCategory, FiniteAlgebraicExtensionField(%), ConvertibleTo(Integer)) But I like the first syntax better. > So your use of "Functor" is somehow like the use of "category" in SPAD. I don't think so. "Functor" just means that the domain that is instantiated by PrimeField depends on a parameter, in this case a value from PositiveInteger instead of some other domain in some specified category. > The intention clearly comes from category theory, but in fact, in SPAD > it is something slightly different. And for that reason I would not like > to introduce/use another category theory term. I agree. I think it is of historical interest only since in appears in some older Axiom literature. > The use of "category" in FriCAS is already confusing enough. Agreed. > And I guess, it was not only me who needed some time to realize > that FriCAS categories are not categories in the sense of CT. Still, there is an important relationship or analogy. Category theory was quite new when Axiom was originally being developed but it appears that some of the developers must have some category theoretic ideas or at least inspiration in mind. > I would like to teach this distinction to new users right at the > beginning. > I would rather address directly the issue of exactly how Axiom relates to category theory. In my opinion category theory should not just be backstage. It is now a fundamental part of mathematics and in particular abstract algebra. I think the original developers of Axiom were incredibly prescient (or maybe just lucky). >> No that is exactly the opposite of what I said I would like. >> I want domains without parameters to be treated the same >> way as domains with parameters. > > OK. But where do you see that I don't already do this? > Just because I write Integer and not Integer()? You do do this already. I did not mean to imply that you did not. The issue for me is how you treat the type of the "return value" of the functor, i.e. the thing that occurs to the right of the -> arrow in the notation above. > > That somehow sounds like the distinction between "sample: %" and > "sample: () -> %". > I do not find this distinction very interesting. I would prefer that () actually denoted a built-in domain in FriCAS - the empty or null cross-product. Instead of defining functions with multiple parameters if type Mapping(A,B,C, ... ), only a two argument Mapping(A,B) should be allowed, but either A or B might replaced with a Cross type. Of course this is already possible except that there currently is no builtin Cross type in SPAD. I would it prefer if all values where treated as side-effect free nullary functions. () -> ... > In fact, we may want to distinguish (in SPAD) > > Foo: Cat == add ... -- (1) > > from > > Foo(): Cat == add -- (2) > > just as in the function case above. > I would vote against it. > Actually that wouldn't hurt me at all (only perhaps some legacy code). > I would probably always use the first definition. > I think the first should just be a convenient shorted form of the second. > And I would be happy if the meaning of "==" in FriCAS changes from > "delayed evaluation" to "definition of constant" just as in Aldor. > I am not convinced that we need to distinquish "constants" in this way. > Then "Foo(): Cat == add ..." would be syntactic sugar for the definiton > of the constant Foo. > > Foo: () -> Cat == (): Cat +-> add ... > > And it becomes clear that the type of (1) is different from the type of (2). > It seems to me that Foo is constant in both cases. Foo always refers to the same function (or functor). In that sense it is already constant. If Foo is not side-effect free in spite of depending on no parameters then this usually should be treated conceptually something like the type of "random variables" with a behavior having well defined bounds. -- 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 http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
