[Aldor-l] implementing aldor / new species approach

[Ralf Hemmecke]

>> Martin, your approach seems to work, but I am still not sure whether it just
>> works because of the current compiler. I would be happier if I had a sound
>> explanation in terms of the *Aldor language* not in terms of the *compiler*.
> 
> I agree. However, if somebody is going to implement Aldor a second time, I'd
> argue that this code working is so useful, that it should be abstracted and
> included in the specification.

Maybe it is already in the specification, but I would like to see 
somebody from aldor.org confirming that it should work.

The code we are speaking about is basically this.

grammar(p: List String): List CombinatorialClass == {
         macro CC == CombinatorialClass;
         import from MachineInteger, List CC;
         A: CC == Atom;
         res: List CC := [A for x in p];
         E(i: MachineInteger): CC == evaluate(parse(p.i), res) add {
#if WantSegfault
#else
                 valuation(): Integer == 1
#endif
         }
         for i in 1..#p repeat res.i := E(i);
         res;
}

p contains a list of strings describing the right hand sides of a set of 
equations. Inside these strings "Self_i" corresponds to the left hand 
side. The left hand sides are assumed to be Self_1,...Self_n.
As you see, first the result list res is initialised by Atom (which is 
just a dummy value). In the for loop at the end the list is 
destructively modified in order to produce the recusively define domains.

Let's abbreviate Self_1 by X and Self_2 by Y. grammar should return a 
list of domains. So what happens if I have the equations

X = Atom * Y
Y = Atom * X

The for loop bothers me. In the first iteration we basically call

evaluate(parse("Atom * Y"), [Atom, Atom])

in the second round we would have

evaluate(parse("Atom * X"), [X,    Atom])

So no matter what evaluate and parse actually do, I simply fear that in 
the end res.1 is not the same domain as res.2 although the above 
equations very much suggest equality.

> Ralf: I quite like your new species file. There is so little code in it that
> is's got to be the right approach :-)

Thanks. It took me long enough to follow the Aldor approach, ie, remove 
restrictions instead of adding functionality. ;-)

> Unfortunately I forgot how to see the
> results of the test cases, and my Aldor compiler is on the other end of the
> modem only... 


 >TestSuited
Looking in BinaryTree(String) for generatingSeries with code 164979209
+--- beginning of test case : TestCombinatorialSpecies
|
|  +--- beginning of test : testBinaryTree
|  | calling setUp function
|  | setUp function finished
|  | ----------------------
|  | calling test function
|  |
|  | failing, because an exception occurred in the test function !
|  | Type:
|  | RuntimeError()
|  | Presentation:
|  | Export not found
|  |
|  | ----------------------
|  | calling tearDown function
|  | tearDown function finished
|  +--- end of test : testBinaryTree( test failed )
|
+--- end of test case       : TestCombinatorialSpecies ( 2 total / 1 
correct / 1 failed tests )


summary of the test suite:
============================

test cases      : 4
tests           : 13
tests succeeded : 12
tests failed    : 1

I don't see how I can go around that "missing function". It should be 
there that is for sure. But maybe blaming the compiler is a bit too early.

> Did you try to leave away the label parameter?

No, I didn't.

 > (although that's one thing I really like! By the way, I guess one can
 > make this parameter optional, don't you think?)

No. By design, you cannot make this optional. Oh, well, perhaps it could 
work, but then you'd have to say EmptySetSpecies() (with parens) since
EmptySetSpecies (without parens is of another type. I am not yet sure 
whether this works, but what do you want it to mean anyway??? What would 
be the default?

Ralf