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