[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: domains with parameters versus Python classes
From: |
Ralf Hemmecke |
Subject: |
[Axiom-developer] Re: domains with parameters versus Python classes |
Date: |
Fri, 30 Mar 2007 10:30:01 +0200 |
User-agent: |
Thunderbird 2.0b2 (X11/20070116) |
On 03/30/2007 05:07 AM, Bill Page wrote:
Ralf,
I have moved your example of a domain with parameters to a
new page and added some explanatory text plus an new example
in Python that does the same thing apparently without the
complication of defining categories. See:
http://wiki.axiom-developer.org/SandBoxSPADForPython2
For Python developers this might be interpreted as an
argument in favor of Python and against Aldor/Spad. So
I think we need to find another more convincing example. :-)
Oh, I seem to learn python... ;-)
Obviously, having the compiler telling me errors just because the types
do not match is not a big argument to Python programmers.
And since Python also allows reflection (cited from
http://wiki.axiom-developer.org/SandBoxSPADForPython2):
if '__cmp__' in dir(self.i):
it allows to do quite a lot of things. For example, a python class can
certainly hold an axiom, like, for example, that the class denotes a
(mathematical) field. So with similar statements one can certainly ask a
class something like:
if R has Field then ...
So a python class knows about its exports and thus can simulate a
category. In Aldor the management of the category information is done
automatically, I Python one would have to call a function if a class
inherits from two or more other classes.
As far as I have understood Python up to now. I Python programmer even
does not need 'information hiding'. A category basically does this, for
example.
MyStupidInteger: with {
0: %;
+: (%, %) -> %;
coerce: Integer -> %;
coerce: % -> Integer;
} == Integer add {
Rep == Integer;
coerce(i: Integer): % == per i;
coerce(x: %): Integer == rep i;
}
This domain basically behaves like Integer, but you cannot multiply
elements since MyStupidInteger does *not* export a multiplication function.
Is this a good thing?
Yes it is. Take the constructor "SortedList" which takes an argument
that must export an ordering function.
SortedList(T: PartiallyOrderedType): with {
BoundedFiniteLinearStructureType T;
DynamicDataStructureType T
} == add {
...
}
If you look up the actual functions that are exported, you won't find:
cons: (T, %) -> %
because with that function you could destroy the properties that the
elements of SortedList(Integer) are (ascendingly) ordered lists of integers.
So if I have SortedList(Integer) there is no way (except for being very
nasty) to create an element which is *not* sorted.
But I guess, that is not a convincing argument to Python programmers.
Ralf
- Re: [Axiom-developer] domains with parameters versus Python classes, (continued)
- Re: [Axiom-developer] domains with parameters versus Python classes, gdr, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Ondrej Certik, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, gdr, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Ondrej Certik, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Gabriel Dos Reis, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Ondrej Certik, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Gabriel Dos Reis, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Ondrej Certik, 2007/03/31
- Re: [Axiom-developer] domains with parameters versus Python classes, Bill Page, 2007/03/30
- Re: [Axiom-developer] domains with parameters versus Python classes, Gabriel Dos Reis, 2007/03/30
- [Axiom-developer] Re: domains with parameters versus Python classes,
Ralf Hemmecke <=