On 06/11/2007 02:55 PM, Stephen Wilson wrote:
Hi Ralf,
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
If you extend Integer then it will not be visible globally. Clearly,
it is visible only for those things that "see" the extension.
Of course you are completely correct. The specific issue I was trying
to point out is illustrated by the following (note that I have not
been able to get Aldor working locally for a long time. Binaries
from aldor.org do not work for some reason.
Send complaints to Stephen Watt and Lauretiu Dragan. But if you have a
64bit machine that could be some problem. There should be a hint by
Christian Aistleitner concerning the 64bit problem in the aldor-l archive.
See also
http://www.aldor.org/pipermail/aldor-l/2005-September/000100.html
and maybe that is also relevant.
http://www.aldor.org/pipermail/aldor-l/2005-June/000074.html
This is from, possibly
bad, memory):
Foo(T: Type): with {
foo: () -> Boolean;
} == add {
if T has with {bar:() -> T} then
foo(): Boolean == true;
else
foo(): Boolean == false;
}
In such a situation, I belive the `has' predicate will see exports
defined via an `extend' occurring in a seperate compilation unit.
Perhaps you could verify?
OK.
---BEGIN aaa.as
#include "aldor"
Foo(T: Type): with {
foo: () -> Boolean;
} == add {
if T has with {binomial: (%, %) -> %} then
foo(): Boolean == true;
else
foo(): Boolean == false;
}
---END aaa.as
---BEGIN bbb.as
#include "algebra"
#include "aldorio"
#library AAA "aaa.ao"
import from AAA;
main(): () == {
stdout << "foo i == " << foo()$Foo(Integer) << newline;
stdout << "foo s == " << foo()$Foo(String) << newline;
}
main();
---END bbb.as
aldor -laldor -fo -fao aaa.as
aldor -lalgebra -laldor -fx bbb.as aaa.o
bbb
foo i == T
foo s == F
But I could have told you the result without actually compiling. The
reason is that Foo is a function and only at the time you call
Foo(Integer) the "has" predicate gets evaluated.
It is more interesting to ask what happens in an interactive
environment. So let's try.
woodpecker:~/scratch>aldor -gloop
AA L DDDD OOO RRRR
A A L D D O O R R
A A L D D O O R R
AAAAA L D D O O RRRR
A A L D D O O R R
A A LLLLL DDDD OOO R R
(c) Numerical Algorithms Group Ltd 1995-2001
Release: Aldor(C) version 1.0.3 for LINUX(glibc2.3) (debug version)
Type "#int help" for more details.
%1 >> #include "aldor"
%2 >> #include "aldorinterp"
%3 >> #library AAA "aaa.ao"
%4 >> import from AAA;
%5 >> foo()$Foo(Integer)
F @ Boolean
%6 >> #include "algebra"
%7 >> foo()$Foo(Integer)
T @ Boolean
You cannot even say that this is wrong or right. Foo(Integer) appears in
a "type context" and according to the Aldor specification, it might or
might not be evaluated.
I always thought Aldor's `extend' was designed to allow for the
enrichment of domains defined within a closed-source library, not as a
general mechanism for solving the kind of mutually recursive
definitions found in Axioms algebra.
I must say, even in an open-source environment, "extend" allows you to
introduce layers of your library and thus allows to put more structure
in the design.
One doesn't have to recompile the whole Axiom library if one thinks that
Integer misses some function. That new function is completely irrelevant
to existing parts of the library and only plays a role in newer parts.
"extend" in my eyes helps to keep libraries maintainable.
Ralf
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
