On Wed, Feb 29, 2012 at 2:53 PM, Serge D. Mechveliani wrote:
> ...
> On Mon, Feb 27, 2012 at 10:38:05PM +0100, Ralf Hemmecke wrote:
> >...
>> In Aldor one would even have the "extend" keyword and so could add new
>> properties/functions to already existing domains.
>>
Although "extend" is part of Aldor, my point of view is that this is
rarely needed and maybe only rarely a good idea in Axiom.
>
> This is the most suspicious thing which I observe in Axiom.
> So far, I hope that I have missed some point. But you are the
> second why mention the feature.
> It is difficult to imagine how can an user behave without adding
> his category instances to the standard library domains.
> For example, in DoCon, I introduce a category (class), say (contrived)
>
> class Sized a where size :: a -> Integer
>
> And usually the first instances for such a category are like this:
>
> instance Sized Integer where size = abs
> instance Sized a => Sized [a] where size = sum . map size
>
> instance (Sized a, Sized b) => Sized (a, b)
> where
> where size (x, y)= (size x) + (size y)
>
> Here Integer, [] := List, and (,) := Pair
> are type constructors from the standard library. And this helps a lot
> the further usage of Sized.
In Axiom categories are not classes. An Axiom category is a kind of
predicate. It must be explicitly asserted by the programmer that a
domain satisfies some category expression (formed from Join and with
clauses). Domains satisfy only the named categories. In addition this
category assertion requires that the domain implement a specific set
of exported operations for which it is the programmers responsibility
to ensure that the operations exported by the domain respect the
axioms that are implicit in the category names which occur in the
category expression. So categories are a kind of "interface contract".
Axiom categories form a lattice of sub-categories based on domain
satisfaction, i.e. Any domain which satisfies category C==Join(A,B)
also satisfies both A and B.
> For example, when an user defines a category Foo, very often,
> Integer must be a member of this category, that is mathematics
> itself strongly requires this. This way things are explained in
> textbooks. Hence an instance of Foo must be defined for Integer.
What you want is that the category assertion of the domain Integer be
extended by the category Foo. In Axiom terms this is tantamount to
asking to change the definition of Integer so that it becomes some new
domain somehow different than the old one, having additional
properties and operations.
> If Spad does not allow this, then this is extremely strange.
> Because the very claim of the Axiom/Spad project was just
> following mathematics in defining algorithms in a generic way.
>
I don't think that it is strange to require that the definition of
domains such as Integer (normally) remain nearly static.
> 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 ?
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.
> Am I missing something?
>
Yes, I think so.
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 INTHEORY IntegerNumberTheoryFunctions
IntegerNumberTheoryFunctions(): with
divisors : Integer -> List(Integer)
...
In your example this would become something like this:
)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.
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.
