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
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
