[Axiom-developer] Re: [Aldor-l] exports and constants

[Ralf Hemmecke]

> Omitted for brevity. Please refer to:
>
> http://wiki.axiom-developer.org/SandBoxAldorSemantics

> See section 5.3 of the Users Guide:
>   "The general syntax for a constant definition is:
>
>       x : T == E
>
>   x is an identifier giving the name of the constant.
>
>   T is an expression giving the type of the constant. The type
>   declaration is optional. If the type is declared, then the type
>   of E must satisfy it. Otherwise the type is inferred from the
>   type of the expression E."

OK. That explains the "E must at least be of type T" which I said in a 
previous post in this thread. But it still does not explain why

#include "aldor"
#include "aldorio"

define CatA: Category == with;
define CatX: Category == with;

A: Join(CatX, CatA) == add;
X: CatX == A;

MyPkg(X: CatX): with {isA?: () -> Boolean} == add {
        isA?(): Boolean == X has CatA;
}
main(): () == { stdout << isA?()$MyPkg(X) << newline; }
main();

outputs "T". Or does it?

> On the other hand if we write
>
>   A: CatA == Dom add
>
> section 5.3 still applies. (So in that sense you are right.)
>
> The difference is that now Dom is the parent domain of a new
> domain: "which specifies a domain from which any or all of the
> exports of the add can be inherited". (Ref: Section 7.8).
>
> So 'Dom add' is a new domain which inherits from Dom, but now
> we need to take into account the rule about the "Visibility of
> inherited operations":
>
>   "whenever an expression 'A add B' appears in a context requiring
>   a domain whose type is the category C, then any operations
>   required by C which are not defined in B are taken from the
>   domain A.
>
> So here the expression 'Dom add' appears in a context requiring a
> domain whose type is CatA, so all operations (and by implication,
> *only* those operations) required by CatA are taken from Dom.

To my understanding, that paragraph from the AUG tells nothing about 
what happens with operations that are not exported through C. In 
particular it says nothing about the type of A that will be seen via an 
"has" expression.


> > ---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
> >
> > woodpecker:~>aldor -fx -laldor aaa6.as
> > woodpecker:~>aaa6
> > 0
> > woodpecker:~>aaa6
> > 0
> > woodpecker:~>aaa6
> > 0
> > woodpecker:~>aaa6
> > 0
> > woodpecker:~>aaa6
> > 0
> > woodpecker:~>aaa6
> > 1
> > woodpecker:~>aaa6
> > 1

> > It's only the type of X that must be clear at compile time.

> I agree that it is the type of X must be clear. But something
> very strange is going on here. I do not get this result in my
> example running Aldor inside Axiom. See again:
>
> http://wiki.axiom-developer.org/SandBoxAldorSemantics
>
> If you write:
>
>   main(): () == {
>         import from X;
>         stdout << foo() << newline;
>         stdout << foo() << newline;
>         stdout << foo() << newline;
>         stdout << foo() << newline;
>         stdout << foo() << newline;
>         stdout << foo() << newline;
>   }
>   main();
>
> You will see that each time you run the program you will only
> get one *constant* result (all 0's or all 1's). But if you run
> the same program repeatedly (as you did above), then sometimes
> you get one result and sometimes the other! Within a given
> runtime of the program, the result is constant and not variable
> as you might be expecting.

I was not expecting any variable behaviour. I declared X to be a 
constant and it was a constant. And, by the way, constant always mean 
"constant in a certain scope". Of course you can define a function

foo(i: Integer): () == {
  k: Integer == i;
  ...
}

So k is constant, but not necessarily constant during the runtime of a 
whole program that uses "foo". It's just constant during execution of 
"foo". So that

  for i in 1..10 repeat foo(i);

is perfectly fine.

Ralf