A trampoline looks like this:
Foo >> trampoline: initialValue into: aUnaryBlock
| v |
v := [initialValue].
[v isBlock] whileTrue: [v := aUnaryBlock value: v value].
^ v.
and then used:
| f factorial |
factorial := 1.
f := Foo new.
f trampoline: 10 into: [ :n |
n <= 0
ifTrue: [factorial]
ifFalse: [factorial := factorial * n. [n - 1]]].
The important thing is that the block returns a value for the base
case/cases of the recursion, and a block that, when evaluated, will
yield the next value on which to recurse. (So the block replaces the
recursive call.)
The trampoline thus turns the recursive algorithm into an iteration.
frank
On 4 May 2013 17:42, stephane ducasse <stephane.duca...@free.fr> wrote:
> can you explain?
> Because I read something like that olong time ago and I forgot
>
> On May 4, 2013, at 5:41 PM, Frank Shearar <frank.shea...@gmail.com> wrote:
>
> 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
>
>
>
