[Aldor-l] [Axiom-developer] spad: language and compiler

[Ralf Hemmecke]

Dear William,

> Getting back to your question, it is up to the programmer to define
> the bracket function for the domain where Martin's expression lives.
> Even though it may not be possible in Axiom to directly program
> tuples of heterogeneous domains, such tuples are present in most
> function signatures like foo:(INT, Boolean)->INT. I would expect
> Aldor therefore to be able to directly program tuples of
> heterogeneous domains.

As you know Record and Cross are two ways in Aldor to construct
heterogeneous tuples. The problem is that both must have a certain fixed
length when you write them into your program.

> Thus Martin's expression, perhaps using round parentheses instead of 
> brackets, should work in Aldor.

Martin's line contained a "for n in primes(1,100)" iterator, so the type
would only be know if the compiler were able to evaluate "primes(1,100)"
at compile time.

> I don't know how "primes" is implemented but it is probably a
> built-in using both a table for lower range and some sophisticated
> algorithms for higher ones.

Whatever "built-in" means for you. It is certainly not built into the 
Aldor language, it is part of a library and as such it could mean 
anything I like.

 > I am not suggesting compile time
> evaluation be extended to all static computations, but my guess is
> "primes" is special. A bit of compiler optimization would probably
> evaluate expressions like 2+3, so why not primes(1,100)?

To what should 2+3 evaluate? To the Integer 5? To the MachineInteger 5? 
To a sparse univariate polynomial 5? To 0 mod 5? It is awfully ambiguous 
and would in general involve more than just a call to the addition of 
machine size integers. I could have even overloaded + for 
MachineInteger. I guess, optimizing 2+3 to 5 is not even correct in some 
circumstances.

>> William is right, but I cannot believe that a construction like
>> 
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>> 
>> would work.
> 
> The main reason why it is not working presently is because we have
> not constructed cartesian product over an arbitrary set of domains.
> But nothing in the language (even Spad) seems to prevent one from
> doing this.

Of course not, but note that you have a generator in the above 
construction and thus the compiler does not know the length of the tuple 
until it is *computed*. To make myself clear: I believe that one can 
write a constuctor for arbitrary tuples of variable length, but Martin's 
syntax to construct an element of such a type would not work. (Please 
convince me otherwise by providing running code.)

>> [f(100, n), f(100, n), f(100, n)]
> 
> You meant: [f(100,2), f(100,3), f(100,5)], I assume.

Of course.

>> should be easily definable and give an element in the cartesian 
>> product of   PF(2), PF(3), and PF(5). But that is a finite
>> construct and not done via Generator as above.
> 
> As discussed above, what is missing is cartesian product over an 
> arbitrary set of domains. If domains are first class objects, we
> should be able to construct sets of them, even via Generator, and
> hence also cartesian product.

Oh, yes, of course it is possible (even now) to construct a 
heterogeneous tuple type via Generator. But Martin's construction would 
mean to construct the type AND the element at the same time. And that (I 
believe) is impossible.

> At the very least, one should be able
> to form a set or list of domains of the same category (which IS
> homogeneous).

No problem in Aldor.

#include "aldor"
U: List PrimitiveType := [Integer, String, Character];

That is a completely valid Aldor program.

>> PFCartesian(k: Integer): with {
 >>     coerce: ((n: Integer) -> PF(n)) -> %;
 >>     ...
 >> }== add { ... }

> I am not following. Is PFCartesian(k) a cartesian product of the
> first k prime fields, like PFCartesian(3) is PF(2) x PF(3) x PF(5)?
> Then given a function (n:Integer)->PF(n) (basically, an sequence of
> elements, one from each PF(n), and n better be a prime! but let's
> pretend we interpret PF(n) as Integer mod n), the coerce function
> maps the anonymous function to PFCartesian(k) by using the first k
> elements in the sequence?

I was not thinking too much about it. I wanted that PFCartesian(7) 
stands for PF(2) x PF(3) x PF(5) x PF(7) and PF for PrimeField. And the 
coerce function basically turns the projection functions into an element 
of PFCartesian.

As representation I could choose

Rep == (n: Integer) -> PF(n);

But I still cannot make

[f(100, n) for n in [2,3,5]$List(Integer)]

into valid Aldor code if f is the function given by Martin.

Can you?

Ralf