On Wed, May 22, 2013 at 09:35:47AM +0400, Denis Kudriashov wrote:
Why Future required compiler changes? What problem to implement #future message as any other method? If it is about performance can you explain why basic implementation should have bad speed? And what benchmarks was used to verify it?
Sorry, I cannot really help because I have no background in this, I only know what I read on the mailing list. There is also a class comment for FutureBuilder in Squeak: "Uses #doesNotUnderstand: to transform messages into future messages. In practice, this class is never used; for efficiency, the Compiler has been modified to use FutureNode to transform code at compile-time to directly send #futureSend:at:args:. However, this is simply an optimization... the semantics are unchanged." Based on this, I would assume that the compiler support is provided only for performance reasons. But I do not have any other information to offer. Dave
2013/5/22 David T. Lewis <lewis@mail.msen.com>
On Mon, May 20, 2013 at 06:26:04PM +0200, Marcus Denker wrote:
No, I know nothing about the Future implementation in Squeak? but a Future node in the AST sounds extremely strange.
I think that the background may be found in this thread:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142111....
Dave