I added a entry in the bugtracker for this so we don't forget:
http://code.google.com/p/pharo/issues/detail?id=2819
On Aug 16, 2010, at 8:53 PM, Eliot Miranda wrote:
>
> BTW here's the VisualWorks 7.7 method. For me it's a little too clever.
>
> whileFalse: aBlock
> "Evaluate the argument, aBlock, as long as the value of the receiver is
> false."
>
> ^self value
> ifFalse:
> [aBlock value.
> [self value] whileFalse: [aBlock value]]
>
> "This method is inlined if both the receiver and the argument are
> literal
> blocks. In all other cases, the code above is run. Note that the code
> above is defined recursively. However, to avoid actually building an
> activation record each time this method is invoked recursively, we have
> used the '[...] whileFalse: [..]' form in the last line, rather than
> the more
> concise 'self whileFalse: aBlock'. Using literal blocks for both the
> receiver
> and the argument allows the compiler to inline #whileFalse:, which (in
> the
> absence of type inferencing) could not be done if we were to use
> 'self whileFalse: aBlock'."
>
> but it's accurate and does the job of turning
> | a b |
> a := [i <= j].
> b := [i := i + 1].
> a whileTrue: b
> into an iterative execution.
>
> So at the very least we should improve the comment in whileTrue: and
> whileFalse: to point to the compiler optimization in MessageNode and IMO the
> VisualWorks implementation is the best compromise between clarity and honesty
> given the lack of tail-recursion elimination.
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
