[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Renaming at inheritance (was: Re: [Axiomdeveloper] Curiosities with
From: 
Ralf Hemmecke 
Subject: 
Re: Renaming at inheritance (was: Re: [Axiomdeveloper] Curiosities with Axiom mathematical structures) 
Date: 
Thu, 02 Mar 2006 13:38:01 +0100 
Useragent: 
Thunderbird 1.5 (X11/20051201) 
Maybe, I am a bit behind ...
On 03/01/2006 05:26 AM, Bill Page wrote:
On February 27, 2006 11:08 AM Gabriel Dos Reis wrote:
...
Ralf Hemmecke <address@hidden> writes:
...
 One reason for having Monoid and AbelianMoniod (one with "*" and
 the other with "+") is that neither SPAD nor Aldor allows to
 rename functions during inheritance.
yes, that is true for many (all?) objectoriented languages. I can
understand the language limitation, but that is hardly an excuse for
chosing in advance that "+" is for Abelian monoid and "*" for
nonAbelian ones.
I don't see why renaming is necessary.
 Note that one would have to say something like

 define Monoid(
 *: (%, %) > %;
 1: %
 ): Category == ...

 define Group(
 *: (%, %) > %,
 inv: % > %,
 1: %
 ): Category == ...

 define Ring(.....): Category == with {
 Monoid(*, 1);
 Group(+, , 0);
 }
Ring should be both Monoid and Group, whether they shoud be
categories, I don't really know.
Well, think of Axiom's Category as just a list of function (and
constant) signatures.
Well, as far as I know, something that is of type Category in
Aldor/Axiom should be near to a mathematical category. (But I am not the
original designer and unfortunately there is no page on the AxiomWiki
that explains it clearly.
Anyway, what I suggested above is perhaps not so close to mathematics as
I and probably other mathematicians would like it to be.
The point is that one speaks of a "category of rings, groups, monoids,
etc.), but not of a "category of rings(*, 1, +, , 0)". So defining
those structures in Axiom without arguments would be highly preferable.
However, there is no way in Axiom to express that a Ring is a Monoid
(SemiGroup if you like) "with respect to multiplication" and a Group
(which is also a Monoid) "with respect to addition".
So the compromise in Axiom currently is to have Monoid and AbelianMonoid
where AbelianMonoid does not inherit from Monoid and one is with respect
to "*" and the other with respect to "+".
However, being a mathematician, it is not so nice that just because of
language limitations I have to construct another algebra hierarchy that
doesn't match the mathematical one.
About two years ago I have spoken to Stephen Watt about a possible way
to rename functions, but he said that would be a major change to the
compiler and very hard to implement. :(
In Axiom (SPAD) we can write:
Monoid(m:Symbol,u:Symbol): Category == with
m: (%,%) > % ++ returns the product of x and y
u: () > % ++ unit
associative(m) ++ m(a,m(b,c)) = m(m(a,b),c)
identity(u) ++ m(a,u) = m(u,a) = a
As you see below, that will not work in Aldor.
begin mon.as
#include "aldor"
define Monoid(m:Symbol,u:Symbol): Category == with {
m: (%,%) > %;
u: () > %;
associative(m);
identity(u);
}
end mon.as
aldor mon.as
"mon.as", line 5: associative(m);
........^
[L5 C9] #1 (Error) There are no suitable meanings for the operator
`associative'.
"mon.as", line 6: identity(u);
........^
[L6 C9] #2 (Error) There are no suitable meanings for the operator
`identity'.
It simply does not match the Aldor language specification.
"associative(m)" is interpreted as call to a function "associative"
which simply does not exist.
And now, something interesting. The following file compiles.
begin mon1.as
#include "aldor"
define Monoid(m:Symbol,u:Symbol): Category == with {
m: (%,%) > %;
u: () > %;
}
end mon1.as
My first guess was that the compiler would complain, because m is a
parameter of type Symbol and now we turn it into a function. But I was
wrong. There are simply TWO m there. One of type Symbol and the other of
type "(%, %) > %" and the have NOTHING to do with each other. They just
happen to have the same name.
That seems to be a difference between SPAD and Aldor.
Then we can write:
)sh Ring(+,,"0"::Symbol,*,"1"::Symbol)
Ring(+,,"0"::Symbol,*,"1"::Symbol) has commutative(+)
See the example at http://wiki.axiomdeveloper.org/SandBoxMonoid
That looks interesting, but as I said above, I would not like Ring to
carry parameters. With parameters, it looks a bit more like a universal
algebra.
Anyway, I think in the above example Axiom's "Symbol" domain (written
*in* the SPAD language) is treated as part of the SPAD language. I
cannot say that I like that. I prefer Aldor's approach even if it
(still) forbids me to do "renaming during inheritance". But I can
understand the code from the language definition.
See also my additions on
http://wiki.axiomdeveloper.org/SandBoxMonoid
 If such renaming could be implemented into the Aldor language
 that would make it even better suited for mathematics. However,
 then there is need that someone implements these ideas into the
 compiler. Who?
Could you explain what you mean by "renaming" and how it might
be used to express mathematics?
Well, clearly a mathematian would always say that an abelian monoid is a
monoid. These properties are properties of the structure and not of the
names of the functions that form that structure.
We cannot express this in Aldor in general, and it is also not done in
Axiom.
Anyway, it is a pity that "Axiom" cannot express axioms in its language.
By the category "AbelianMonoid" one has just a tag that domains that
implement this category have to implement "+: (%,%)>%" in a commutative
fashion. The only way to state commutativity is in the documentation,
but not formally in a language construct.
There are some experiments, however...
http://citeseer.ist.psu.edu/poll98adding.html
http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/index.html
> Not all, Eiffel can rename methods when inheriting:
>
> http://www.maths.tcd.ie/~odunlain/eiffel/intro.html
> """
> class C inherit
>
> A rename x as x1, y as y1 end;
>
> B rename x as x2, y as y2 end
>
> feature...
>
> Here, if both A and B have features named x and y, class C would be
> invalid without the renaming.
I don't know Eiffel, but I guess that feature is necessary for multiple
inheritance.
In Aldor multiple inheritance is already possible for categories, but
forbidden for domains.
But I would like to say something like
define SemiGroup: Category == with {
*: (%, %) > %  or any other name.
}
Ring: Category == with
SemiGroup;
SemiGroup where {* == +};
}
Oh that will be getting complicated if I inherit from something like
define Structure: Category == with {
foo: % > %;
foo: (%, %) > %;
}
Where are the language designers?
Ralf
 Re: Renaming at inheritance (was: Re: [Axiomdeveloper] Curiosities with Axiom mathematical structures),
Ralf Hemmecke <=