[Aldor-l] [Aldor-combinat-devel] Should this "parser" work?

[Ralf Hemmecke]

> So this bit boils down to the question: what does constancy mean. In fact, AUG
> is quite explicit here:
> 
> The names appearing in an expression in type context may be
> 
> * defined via "=="
> * imported via "import", or
> * function parameters which are nowhere updated.
> 
> So, I guess, res.i := something is not allowed.

Sounds wrong to my ears. It says, that "res:=something" is not allowed.
"res.i:=something" doesn't change the "constant" status of "res". That 
sounds strange, but I believe that it is true in aldor.

I don't remember where you started with, but I guess the code from 
aldor-combinat/trunk/combinat/src/grammar.as.nw (revision 84)

grammar(p: List String): List LabelSpecies == {
         import from MachineInteger, LabelSpecies, List LabelSpecies;
         A: LabelSpecies == coerce EmptySetSpecies;
         res: List LabelSpecies := [A for x in p];
         E(i: MachineInteger)(L: LabelType): CombinatorialSpecies(L) ==
           (coerce evaluate(parse(p.i), res))(L) add;
         for i in 1..#p repeat res.i := coerce E(i);
         res;
}

is quite similar to the code you gave initially. But here clearly res is 
*not* a constant, since it is defined via ":=". I've just replaced it by 
"==" and "make check" still succeeds.

Why that grammar code works, probably comes from the fact that E(i) gets 
evaluated in the "for" loop, but *not* E(i)(L) for some particular L. 
(Wild guess on my side.) Only when you access the result of "grammar", 
some real work is done. But at that point the entries in "res" point to 
the thing you want. You basically delay everything by working with 
functions.

Another instance where people from aldor.org should contribute. 
Otherwise, we might just waste our time for things that is completely 
clear to people at aldor.org.

> I really hope that the current situation changes, i.e., that Aldor becomes free

The big question is *when* will that happen. I haven't seen much 
movement. :-(

> and that people who are interested can work on an Aldor 2, which is a little
> less restrictive...

Maybe it's just that the AUG is not clear enough for our case. The 
really bad thing is that there is no support from aldor.org to sort out 
this  problematic "recursive definition of multiple domains inside 
functions" stuff. Or has somebody received private mail from aldor.org 
concerning this issue?

> BTW, did you look at Ralf's code for defining series recursively? I wouldn't be
> surprised if similar difficulties as here would arise with respect to
> "standard" conformance...

I don't think that they are problematic with respect to Aldor. The 
"approximateOrder" computation is something that still worries me until 
I have proved that it must always terminate or under which conditions 
that terminates.

I explicitly implemented lazyness at the price of being unable to write

t: Series == x + t*t;

I have to write

t: Series == new();
set!(t, x+t*t);

For species, we can write something like in the first equation. Of 
course, we could also do things in the way I do it with series, but then 
the question arises, *why* are we using Aldor? Rewriting the current 
code into the other form basically means to neglect the expressiveness 
of Aldor.

Ralf