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 <[email protected]> > > > 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.html > > > > Dave > > > > > >
