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

[Page, Bill]

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.