On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote: > ... > 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. > ...
What does "fixed" mean in this context? > Martin's line contained a "for n in primes(1,100)" iterator, > so the type would only be known if the compiler were able to > evaluate "primes(1,100)" at compile time. >From our earlier discusion of 'random()' in the context of Aldor types that are determined at compile-time, it seems clear that it should be no problem to define a constant such as P:List Integer == primes(1,100); In fact, 'primes(1,100)' is a constant expression. As we discovered, although P is a constant it's actual *value* is only determined during run-time initialization, and then it is fixed for the duration of the program execution. I recall that you demonstrated in several programs that types in Aldor (which must be constant) are also evaluated in exactly this way. At first I found this very surprising but now I am pretty happy about it. :) That this is the case should not really be so surprising considering that one of the target runtime environments for Aldor is lisp! Anyway I see no reason in principle for Aldor to reject something like: [f(100,n) for n in P]::Cross(PF(n) for n in P) where the bracket function is define by the Cross domain constructor. This is not the only type which satisfies Martin's original example. Another possibility is: [f(100,n) for n in P]::List Union(n:PF(n) for n in P) i.e. a List over a type union. This would be a more general type than the cross product, but equally valid from a conceptual point of view. > ... > >> 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. I am afraid that there may indeed be such a restriction -- at least in SPAD. The problem is how and when the arity of functions is decided. The arity is actually encoded into the names given to the functions and as far as I know these names *must* be decided strictly at compile-time. The situation in Aldor might be different but I do not understand in sufficient detail the actual FOAM that Aldor generates. > > 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*. Although the length is not known at compile-time, nontheless it is fixed at run-time initialization. That is not an unusual sitation in Aldor. > > Oh, yes, of course it is possible (even now) to construct a > heterogeneous tuple type via Generator. Really? > But Martin's construction would mean to construct the type > AND the element at the same time. And that (I believe) is > impossible. > ... > 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. > Probably what we need is some kind of recursive type constructor. See for example: http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as Something like ... ? PFCartesian(k: Integer): Type == if k<=1 then PF(1) else Record(fst:PF(k),rst:PFCartesian(k-1)); See also section 23.8 "Recursive Strurctures" page 324 of the Axiom Library Compiler Users Guide, 1994: www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf I hope to have more time some to work with these examples. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer