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.duca...@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.clem...@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.clem...@gmail.com> >> 2013/5/4 stephane ducasse <stephane.duca...@free.fr> >> >> On May 4, 2013, at 1:04 AM, Igor Stasenko <siguc...@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.alle...@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.duca...@free.fr> wrote: >> >>> >> >>> >> >>> >> >>> Begin forwarded message: >> >>> >> >>> From: Camillo Bruni <camillobr...@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-st...@lists.gforge.inria.fr> >> >>> Reply-To: RMoD private list <lsehub-st...@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 >
