Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > | Note that at first I thought that introducing Aldor's extend would
> > invalidate
> > | my reasoning. But it turns out, that at least the current Aldor compiler
> > does
> > | *not* allow overriding domain definitions either. I could not find
> > anything
> > | appropriate in the Aldor User Guide though.
>
> Martin, what exactly do/did you mean by that?
[EMAIL PROTECTED]:~/aldor-test$ aldor -fx -laldor override.as
[EMAIL PROTECTED]:~/aldor-test$ ./override
foo()$Bar: foo$Bar
bar()$Bar: foo$Bar + bar$Bar
foo()$Foo: foo$Foo
bar()$Foo: foo$Bar + bar$Bar
Thus, bar$Foo calls foo()$Bar. The call to foo in Bar was *not* replaced by
foo()$Foo.
[EMAIL PROTECTED]:~/aldor-test$ aldor -fx -laldor -DWithExtend override.as
[EMAIL PROTECTED]:~/aldor-test$ ./override
foo()$Bar: foo$Bar
bar()$Bar: foo$Bar + bar$Bar
foo()$Foo: foo$Ext
bar()$Foo: foo$Bar + bar$Bar
The same is true even if we extend Foo.
Gaby wrote:
> although it [Axiom] tends to treat operations from add-chains as if they were
> from default categories or default packages (except that add-chains take
> precedence over defaults). So, that implies to me -- given the way defaults
> work -- that domains can see operations overriden if used in add-chains.
> However, newLookupInTable seems to implement that behaviour only when the
> package is a default. I do not know whether it is a bug of feature, but I do
> want a unifrom behaviour (which tends to push the current behaviour toward a
> bug).
I think I can live with both - and I even agree that the current (and Aldor's)
behaviour is somewhat inconsistent. Note that in aldor, the keyword "default"
is used to introduce default implementations in categories.
On the practical side, it allows an optimization which I believe is quite
important. Without the optimization, it makes a (big) difference whether in
IIARRAY2 you write (1)
minRowIndex m == mnRow
minColIndex m == mnCol
qelt(m,i,j) ==
qelt(qelt(m,i - minRowIndex m)$Rep,j - minColIndex m)
or (2)
minRowIndex m == mnRow
minColIndex m == mnCol
qelt(m,i,j) ==
qelt(qelt(m,i - mnRow)$Rep,j - mnCol)
In fact, I'm not sure what we want. Somehow, default implementations are a
mixed blessing...
I just thought, it might well be better to forget about the to-be optimization
and code as in (2), however, then one might just as well have the optimization
done automatically. Is it desirable that (1) and (2) have different semantics?
I guess that allowing default implementations really only makes sense in
categories, where not all operations are known.
Martin
#include "aldor"
#include "aldorio"
Bar: with {
foo: () -> String;
bar: () -> String;
} == add {
foo(): String == "foo$Bar";
bar(): String == foo() + " + bar$Bar";
}
Foo: with {
foo: () -> String;
bar: () -> String;
} == Bar add {
foo(): String == "foo$Foo";
}
#if WithExtend
extend Foo: with {
} == add {
foo(): String == "foo$Ext";
}
#endif
stdout << "foo()$Bar: " << foo()$Bar << newline;
stdout << "bar()$Bar: " << bar()$Bar << newline;
stdout << "foo()$Foo: " << foo()$Foo << newline;
stdout << "bar()$Foo: " << bar()$Foo << newline;
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
