So use a trampoline. Then you can define your recursion naturally, in constant stack space.

frank

On 04 May 2013, at 16:08, stephane ducasse <stephane.ducasse@free.fr> wrote:

I understand why he wants that :)

no stack explosion�

Stef

On May 4, 2013, at 12:37 PM, Cl�ment Bera <bera.clement@gmail.com> wrote:

To be more precise, for the method :

foo 

        ^ 1 + 2

AST will be :

     ^

       \ 

        +

       /  \

      1   2

AST Interpreter, to interpret ^, will do something like :

start interpret ^

      interpret subnode of ^

      start interpret +

            interpret subnodes of +

                  interpret 1

                  interpret 2

            interpret + with subnodes interpretation result

      end interpret +

      interpret ^ with subnode interpretation result

end interpret ^

Igor would like to have a flatten AST that would be in an array like :

#( 1  2  +  ^ )

Then you can interpret it with a loop

[currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode nextNode ].

And interpretation looks like :

interpret 2

interpret 1

interpret + with two precedent results on stack

interpret ^ with precedent result on stack

2013/5/4 Cl�ment Bera <bera.clement@gmail.com>

2013/5/4 stephane ducasse <stephane.ducasse@free.fr>

On May 4, 2013, at 1:04 AM, Igor Stasenko <siguctua@gmail.com> wrote:

> Did i said already that i don't like how ASTInterpreter implemented? :)

We will let perfection for later :)

It is not a question of perfection or so.

Igor does not like that we interpret recursively the AST instead of with a loop (ASTInterpreter>>interpret: calls itself again and again). He would like to have a flatten-AST-interpreter, with a loop like: 

[currentASTNode hasNextNode] whileTrue: [ self interpret: currentASTNode nextNode ].

 But Camillo and I don't want that because it interprets a flatten AST, not a tree.

>
> Nevertheless, it is useful.. and this case clearly demonstrates that.
>
> On 4 May 2013 00:14, Clara Allende <clari.allende@gmail.com> wrote:
>> This is great news! Are you going to publish the code? it will come in handy
>> for my summer of code :D
>>
>
> Camillo has the image
>
>>
>> On 3 May 2013 03:21, stephane ducasse <stephane.ducasse@free.fr> wrote:
>>>
>>>
>>>
>>> Begin forwarded message:
>>>
>>> From: Camillo Bruni <camillobruni@gmail.com>
>>> Subject: [Lsehub-staff] How to Debug :D
>>> Date: May 2, 2013 6:22:06 PM GMT+02:00
>>> To: RMoD private list <lsehub-staff@lists.gforge.inria.fr>
>>> Reply-To: RMoD private list <lsehub-staff@lists.gforge.inria.fr>
>>>
>>> Igor: Camillo can you help me debugging this strange athens rendering bug
>>> Cami: sure
>>>
>>> Igor: where do you think the bug is? The green path jumps if I change the
>>> Y coordinate and it shouldn't...
>>> Cami: no clue...
>>>
>>> Igor: Any clue how to get to the bug?
>>> Cami: let's use the ASTInterpreter to interpret two methods with different
>>> transformation matrices and see when they diverge.
>>>
>>> Result:
>>> -------
>>> - after 1h comparing AST Debugger is ready
>>> - we run the two traces, they do NOT diverge => ????
>>>
>>> Conclusion:
>>> -----------
>>> Cairo, which was chosen as reference, did not properly draw the path!!!
>>>
>>> So we should publish the code of the ComparingInterpreter a bit and we
>>> can use it for a few more tasks in Pharo ;)
>>>
>>>
>>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

--
Cl�ment B�ra

Mate Virtual Machine Engineer

B�timent B 40, avenue Halley 59650 Villeneuve d'Ascq