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

[Christian Aistleitner]

Hello,

On Fri, 20 Oct 2006 15:12:54 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> Hmm, although I said similar things before, I am somehow sure that
> section 7.3 does not apply. We are talking about the part that comes
> behind the "add".

Sorry, it was not clear to me from the original posting that we are  
talking about the part _after_ the add.
In that case you are of course right -- section 7.3 does not apply.

> If you consider that separately then we have
>
>    add { expr1; expr2; ... exprk }
>
> The stuff in braces is a 'sequence' (separated by ; not by ,) so the
> evaluation order is as written.

I am not really sure about this. For general sequences of code, you are  
right, I guess. But here we are after an “add", which is a special  
situation.

I constructed some code to show some possible issues.

The following code is rather unreadable. Nevertheless, the unreadability  
is inherent, to get to see the states, where execution currently is.
I use the Integer “seq” to track the progress of execution. Printing to  
stdout gives some inherent evaluation problems, so I could not use that.

An output of 30000200001, means that the program first reached state 3,  
then 2, then 1.

Now on to the code. The important part is the calling of funcA within the  
“add", before it was defined.


#include "aldor"

import from Character, TextWriter, String, Integer;
local seq: Integer := 0;
macro seqBase == 100000;
macro markState( A ) == { seq := seqBase * seq + A; }

SomeCat: Category == with {
         funcA: ( a: Integer == ( free seq; markState( 1 ) ) ) -> Integer;
};

markState( 51 );

SomeDomA: SomeCat with {
         funcA: ( a: Integer == ( free seq; markState( 11 ) ) ) -> Integer;
} == add {

         free seq;

         stdout << "Executing add part ..." << newline;

         markState( 21 );

         stdout << "funcB" << newline;
         local funcBRes := funcA();
         stdout << "   " << funcBRes << newline;

         markState( 22 );

         funcA( a: Integer == ( free seq; markState( 23 ) ) ): Integer == {
                 markState( 24 );
                 a;
         }

         markState( 25 );

         someConst: Integer == markState( 26 );

         stdout << "Executing add part done" << newline;
         markState( 27 );

};

markState( 52 );

markState( 53 );
stdout << "funcA" << newline;
markState( 54 );
funcARes := (funcA$SomeDomA) (  );
markState( 55 );
stdout << "   " << funcARes << newline;
markState( 56 );
stdout << "seq: " << newline;




When compiling and executing, I get:

____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx -l  
aldor test.as && ./test
#1 (Warning) The file `test.c' will now be out of date.
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
funcA
Executing add part ...
funcB
    51000520005300054000010002100023
Executing add part done
    5100052000530005400001
seq:
    510005200053000540000100021000230002400022000250002600027000240005500056


The important part is 210002300024. During evaluation of the “add” part,  
between states 21 and 22, funcA is called. At that time, it may be known  
that some implementation of funcA has to be is scope (because of the  
inheritence of SomeCat, or via the additional with part).
However, funcA cannot have a value yet, as it is defined only after state  
22.
Nevertheless, it is possible to effectively call funcA, as the above code  
succeeds.
The compiler has to shift funcA upwards, otherwise this would not be  
possible.
However, the compiler does not shift someConst upwards, as 2500026 shows.

Both, funcA and someConst, are constants.

Both are side-effecting (through markState). Which partly counters your  
claim

> In particular, I was once told by some Aldor developerthat constant  
> declarations are moved up as far as
> possible in the evalution process.

from
http://www.aldor.org/pipermail/aldor-l/2006-October/000489.html
, as it would be strange if Aldor would recognize only one of the two  
identical side-effects.

To further underpin the upward shift of funcA, replace

funcA( a: Integer == ( free seq; markState( 23 ) ) ): Integer == {
         markState( 24 );
         a;
}

by a trivial conditional wrapping like:

if ( 0 = 0 ) then
{
         funcA( a: Integer == ( free seq; markState( 23 ) ) ): Integer == {
                 markState( 24 );
                 a;
         }
} else {
         funcA( a: Integer == ( free seq; markState( 23 ) ) ): Integer == {
                 markState( 24 );
                 a;
         }
}


Compiling and executing gives:
____________________________________________
tmgisi at spencer
cwd: ~/aldor
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx -l  
aldor test.as && ./test
#1 (Warning) The file `test.c' will now be out of date.
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
funcA
Executing add part ...
funcB
Looking in SomeDomA for funcA with code 344215503
Unhandled Exception: RuntimeError()
Export not found


This error shows that now funcA has not been shifted upwards and therefore  
cannot be called.
Nota bene: At compile time, the compiler correctly thinks that there has  
to be some funcA.



--
Kind regards,
Christian