On Fri, Mar 30, 2012 at 9:51 AM, Serge D. Mechveliani <[email protected]> wrote: > Earlier, we wrote about adding instances to a library domain: > ... > Bill Page: >> ... >> In Axiom there is a way to introduce new operations related to Integer >> without redefining what you mean by Integer. This is done by defining >> a package. It is common to see in the Axiom library for example >> something like: >> >> )abbrev package SIZED Sized >> Sized(A:OrderedRing): with >> size: A -> Integer >> size: List A -> Integer >> size: DirectProduct(2,A) -> Integer >> == add >> size(a:A):Integer == abs(a) >> size(a:List A):Integer == reduce(+,map(size$SizedInt(A),a)) >> size(a:DirectProduct(2,A)):Integer == size(first a)$SizedInt(A) + >> size(second a)$SizedInt(A) >> >> Note: This code is just of illustration. I haven't actually tried to >> compile it. > > > Consider the following concrete example. I define > > -------------------------------------------------------- > ParseCategory : Category == SetCategory with > parseElem : String -> Product(%, String) > ++ parseElem parses from String and yields > ++ construct(<parsed element> : %, <remaining string>). > ++ Example: parseElem("- 12 x1") :: Product(Integer, String) -> > ++ construct(-12, " x1") > -------------------------------------------------------- > Then, to spread parseElem to the appropriate library domain constructors, > I need to do the following. > 1) Add ParseCategory to Integer and to implement it.
This does not make sense. ParseCategoery does not have to be part of Integer as my example illustrates. > 2) Implement ParseCategory for F := Fraction R, where R has > IntegralDomain, ParseCategory, > and parseElem for F is expressed via parseElem for R. > 3) Similarly, implement ParseCategory for P := UP(v, R), where R > has ParseCategory, and parseElem for P is expressed via parseElem > for R. > 4) Similarly, implement ParseCategory for P := MPOLY(vars, R), > > -- and so on, may be, for 20 library constructors. > And I could not imagine any other natural way of programming things. > Please look at the example of a package in Axiom. > Now, how to avoid making 20 copies of these parametric library domains? > How does your approach with a package apply to this example? > > So far, I am going to try adding parseElem to my packages, like this: > > ----------------------------------------------------------- > )abbrev package UPOL1 UPol1 > UPol1(v : Symbol, R : Ring) : Export == Implementation where > > P ==> UP(v, R) > ParseCoefFunction ==> String -> Product(R, String) > Export == with > ... > parseElem : (ParseCoefFunction, String) -> Product(P, String) > > Implementation == add > ... > parseElem(parseCoef : ParseCoefFunction, str : String) : > Product(P, String) == > > <parsing a polynomial expressed via parseCoef> > ----------------------------------------------------------- > > But > 1) I do not know, so far, how this will work in the whole project, I works in the rest of the Axiom library. > 2) passing a parsing function as an argument actually means refusing to > define and use the user categories. > This entire exercise appears to be based on a misunderstanding of the basic design of Axiom. What you seem to be trying to do in already a fundamental part of Axiom. You should study the code for interpret and especially the package InputFormFunctions1 Regards, Bill Page. -- 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.
