Earlier, we wrote about adding instances to a library domain:
>> Now, if one needs to use this Sized for Integer in Spad, one has
>> to define a copy domain Integer2 and add an implemantation of
>> Sized to Integer2 ?
Bill Page:
> This is facilitated by the use of
>
> == Integer add ...
>
> in your definition of Integer2.
>> And to write almost everywhere in the program Integer2 instead of
>> Integer ??
>> And if the program uses 50 library domains in a simialr way, one needs
>> to create 50 more domains or constructors and use 50 different names
>> for them ??
>> MyList, MyProduct, MyInteger, MyFraction, MyUP, MyPOLY, MyMatrix ... ?
> No, this is normally not necessary.
> [..]
>
> 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.
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.
Nowm, 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,
2) passing a parsing function as an argument actually means refusing to
define and use the user categories.
Regards,
------
Sergei
[email protected]
--
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.
