[Aldor-l] extracting the grammar from a species and isomorphismtypegeneratingfunction

[Ralf Hemmecke]

On 10/19/2006 12:18 PM, Martin Rubey wrote:
 > Dear Ralf, *
 >
 > I ported the support for extracting the grammar from a given 
CombinatorialSpecies to your new library. (which is really cool, I
 > should add once more...)

Well, I should check in my "Compose" stuff..., but it should come with
testcases... But I don't have testcases for the structures anyway.

 > Doing so I also made isomorphismTypeGeneratingSeries work. The
 > crucial thin is that, when you have several "recursive" structures,
 > you have to introduce all the names before you refer to them. I.e.,
 >
 > generatingSeries: ExponentialGeneratingSeries == new(); 
isomorphismTypeGeneratingSeries: OrdinaryGeneratingSeries == new(); 
grammar: Grammar == new();

 > set!(generatingSeries$%, generatingSeries$F(L) *
 > generatingSeries$G(L)); set!(isomorphismTypeGeneratingSeries$%,
 > isomorphismTypeGeneratingSeries$F(L) *
 > isomorphismTypeGeneratingSeries$G(L)); set!(grammar$%, apply("Times",
 > grammar$F(L), grammar$G(L)));

As usual, you just give meta statements that make it hard for me to follow.

 > If instead you say
 >
 > generatingSeries: ExponentialGeneratingSeries == new(); 
set!(generatingSeries$%, generatingSeries$F(L) *
 > generatingSeries$G(L));

 > grammar: Grammar == new(); set!(grammar$%, apply("Times",
 > grammar$F(L), grammar$G(L)));

 > Aldor will complain that grammar is missing from F(L), since the
 > first set! statement made it instantiate F(L) and it never reached
 >
 > grammar: Grammar == new();

(Now my guess is that you are talking about the constructor "Times" in
svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk/combinat/src/species.as.nw
(revision 71) -- so that the aldor-l people have a chance to follow the
discussion).

I don't yet know what you mean by "Grammar". :-( , but anyway if the
order is a problem, then I consider that a real problem of the compiler.

Your explanation does not sound correct. Times takes two parameters namely

   Times(F: SPECIES, G: SPECIES): ...

where

macro SPECIES == (L: LabelType) -> CombinatorialSpecies L;

so what grammar$F(L) is has nothing to do with grammar$%.

Arrrrrrrhhhhh. Now I understand... You actually mean Times as used in
test/species.as.nw

testRecursive1b(): () == {
         macro {
                 I == EmptySetSpecies;
                 X == SingletonSpecies;
                 + == Plus;
                 * == Times;
         }

         A(L: LabelType): CombinatorialSpecies L == (X + A*A)(L) add;

         import from Integer, Array Integer;
         checkExpOrd(
             A,
             [0, 1, 2, 12, 120, 1680, 30240],
             [0, 1, 1, 2, 5, 14, 42]
         );
}

The problem now is that F=G=%. Recursion is the problem. (Martin, please
make your description more explicit. It is hard to guess all the time.)

In that case I can see that the compiler might have trouble with the
order of the functions. Hmmm...., bad for Aldor-Combinat. :-(

 > I'm not quite sure whether this is a bug or a feature.

I am not sure, but I guess, that this is not really a compiler bug.

 > Is the order of evaluation during domain instantiation fixed and
 > documented? (I asked this before, did I?)

IIRC, it is fixed, saying that one cannot completely rely on the order 
of evaluation. In particular, I was once told by some Aldor developer 
that constant declarations are moved up as far as possible in the 
evalution process. That would probably have helped in our case, but 
clearly in

egs: EGS == new();
set!(egs$%, egs$F(L) * egs$G(L));
ogs: OGS == new();
set!(ogs$%, ogs$F(L) * ogs$G(L));

it is hard for the compiler to exchange the lines

set!(egs$%, egs$F(L) * egs$G(L));

and

ogs: OGS == new();

I even guess, your suggestion to exchange the order of these lines by 
hand is not the right solution in general, since one cannot rely on the 
evaluation order.

I think the better solution is to create a function

init(): () == {
   set!(egs$%, egs$F(L) * egs$G(L));
   set!(ogs$%, ogs$F(L) * ogs$G(L));
   ...
}

and call it at the end of the "add" expression.
Not so nice, but seems to be unavoidable.

 > Can I check in my code?

Martin, I would like to see your code before I allow to modify the 
trunk. Could you modify your branches/experiments/rubey branch to 
contain the new code if you are ready, tell me, I'll look at it and then 
we (or you) merge it to the trunk.

Ralf