Hello Christian,
On 07/21/2006 09:47 AM, Christian Aistleitner wrote:
[...]
#include "aldor"
import from String, TextWriter, Character;
define CatA: Category == with { }
define CatB: Category == with { }
define SomeCat: Category == with { CatA; CatB; }
Dom: SomeCat == Integer add;
B: CatA == Dom;
stdout << "B has CatA: " << ( B has CatA ) << newline;
stdout << "B has CatB: " << ( B has CatB ) << newline;
func( DomParam: CatB ):() == { stdout << "called func" << newline; }
C_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx
-lalgebra -laldor -D IFCLAUSE test2.as && ./test2
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
B has CatA: T
B has CatB: T
We see B's dynamic type has bath CatA and CatB.
However,
func( B )
complains about B being only CatA and not also CatB.
func( Dom )
works.
I don't see what you mean.
What about the following:
Universe of the compiler before B: CatA == DOM:
Dom ( StaticType: SomeCat; Implementation at memory location 123456 )
After the B: CatA == Dom:
Dom ( StaticType: SomeCat; Implementation at memory location 123456 )
B ( StaticType: CatA; Implementation at memory location 123456 )
That would be OK for me, but currently the last line probably reads
B ( StaticType: SomeCat; Implementation at memory location 123456 )
since the ": CatA" has no influence on the type of B. (That's what the
compiler says. I am not sure what the language defines in that case.)
---BEGIN aaa5.as
#include "aldor"
define CatA: Category == with;
define CatB: Category == with;
define CatX: Category == with;
A: Join(CatX, CatA) == add;
B: Join(CatX, CatB) == add;
#if ADD
import from MachineInteger;
X: CatX == if odd? random(10) then (A add) else (B add);
#else
X: CatX == if true then A else B;
#endif
---END aaa5.as
>aldor -fx -laldor -DADD aaa5.as
compiles without any complaints. Now try without the ADD assertion.
>aldor -fx -laldor aaa5.as
"aaa5.as", line 14: X: CatX == if true then A else B;
...........^
[L14 C12] #1 (Error) Have determined 0 possible types for the expression.
Subexpression `A':
Meaning 1:
Join(CatX, CatA) with
==...
Subexpression `B':
Meaning 1:
Join(CatX, CatB) with
==...
The context requires an expression of type CatX.
Are you now a bit more puzzled?
Random things are not the problem. Obviously "A" and "A add" are not
(treated) identical by the compiler.
It's getting tricky to put my thoughts into correct words, but I guess:
Once the value of "A" and "A add" are established, they are treated
equally. But these expressions give different values. "A add" gives an
expression of type CatX. "A" gives an expression of type Join( CatX,
CatA ). And the compiler cannot infer properly, that Join( CatX, CatA )
provides CatX.
I think I should try a little piece of code here to claim that "A add"
cannot just give something of type CatX. We all know that it is a
perfect value in Aldor and thus must have a type of its own. The only
type I can think of for "A add" is that of "A" so it would be
Join(CatX,CatA). But then some miracles happen if you say
X: CatX == A add;
That simply forgets the CatA exports.
Now let's make things a bit more complicated. Would you be able to guess
the output of the following program?
---BEGIN aaa7.as
#include "aldor"
#include "aldorio"
define CatA: Category == with;
define CatX: Category == with;
A: Join(CatX, CatA) == add;
X: CatX == A add; stdout << (X has CatA) << newline;
Y: CatX == A; stdout << (Y has CatA) << newline;
#if WITHZ
Z: CatA == Y; stdout << (Z has CatA) << newline;
#endif
---END aaa7.as
Right.
>aldor -grun -laldor aaa7.as
F
T
>aldor -DWITHZ -grun -laldor aaa7.as
"aaa7.as", line 11: Z: CatA == Y; stdout << (Z has CatA) << newline;
...........^
[L11 C12] #1 (Error) There are 0 meanings for `Y' in this context.
The possible types were:
Y: CatX, a local
The context requires an expression of type CatA.
So the compiler now thinks that the type of Y is just CatX. OK, but then
why can the program print "T" in the previous compilation?
If that is not to be considered a bug then I don't know what to say.
Now if we assume that
X: CatX == if true then A else B;
yield an X of the type of the domain on the right hand side then the
compiler has to match the types of A and B (they have to be equal).
Try to replace B by A in the code above and the compiler will not
complain anymore.
Not true for me--I still get the corresponding errors:
#include "aldor"
define CatA: Category == with;
define CatB: Category == with;
define CatX: Category == with;
A: Join(CatX, CatA) == add;
B: Join(CatX, CatB) == add;
X: CatX == if true then B else A;
Sorry, I meant
X: CatX == if true then A else A;
(no B anymore).
---BEGIN aaa6.as
#include "aldor"
#include "aldorio"
macro I == MachineInteger;
define CatX: Category == with {foo: () -> I}
A: CatX == add {foo(): I == 0;}
B: CatX == add {foo(): I == 1;}
import from MachineInteger;
X: CatX == if odd? random(10) then A else B;
main(): () == {
import from X;
stdout << foo() << newline;
}
main();
---END aaa6.as
[ ... ]
The interesting part of aaa6.as is that now if one writes
X: CatX == if odd? random(10) then (A add) else (B add);
(with the "add"), the program does not compile anymore in contrast to
aaa5.as above.
>aldor -fx -laldor aaa6.as
"aaa6.as", line 13: stdout << foo() << newline;
..................^
[L13 C19] #1 (Error) There are no suitable meanings for the operator
`foo'.
But I guess, that's a different issue, as X has the foo function and
allows to call it, as demonstrated by
#include "aldor"
#include "aldorio"
macro I == MachineInteger;
define CatX: Category == with {foo: () -> I}
A: CatX == add {foo(): I == 0;}
B: CatX == add {foo(): I == 1;}
import from MachineInteger;
X: CatX == if odd? random(10) then (A add) else (B add);
main(): () == {
import from X;
stdout << (X has with{ foo:() -> I }) << newline;
stdout << ((foo$X)()) << newline;
}
main();
LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx
-lalgebra -laldor test2.as && ./test2 && sleep 1 && ./test2
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
T
1
T
0
I am amazed. I had also tried foo()$X but the compiler still complained.
Ciao
Ralf
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer