On 20 May 2013 17:26, Marcus Denker <[email protected]> wrote: > > On May 20, 2013, at 6:16 PM, Frank Shearar <[email protected]> wrote: > >> On 20 May 2013 16:57, Marcus Denker <[email protected]> wrote: >>> >>> On May 20, 2013, at 4:44 PM, Paul Davidowitz <[email protected]> wrote: >>> >>>> I just started following this Dev mailing list, and I saw that 'AST >>>> Everywhere' and 'Reflectivity' were mentioned as very promising (I >>>> already know about Slots). >>>> Can someone in a nutshell please describe these developments? Thanks, >>> >>> >>> Right now, the compiler uses it's own AST, Syntax highlighting uses a very >>> minimal >>> token stream (and it's own parser), the refactoring engine has one, too. >>> And then there is Bytecode which is used by the Debugger, for example. >>> >>> As a first step we plan to use the Refactoring AST for everything >>> (Compiler, Refactoring, Syntax highlighting ) >> >> I keep forgetting to ask - does the Refactoring AST have an equivalent >> of Squeak's FutureNode? > > No. > >> (It's not semantically necessary to have one >> to support futures; it's a performance enhancer.) >> > > Now that sound *very* odd. An AST Node is by definition something > that is a grammatical element of the language. > If you write down the grammar of Smalltalk, there is no "Future" there, > so in the AST there is none modeled, either. > > No, I know nothing about the Future implementation in Squeak… but > a Future node in the AST sounds extremely strange.
It's a compile-time transformation of #future and #future: messages. Depending on whether or not the result is used (through some basic semantic analysis) the messages are transformed into #futureDo:at:args or #futureSend:at:args. FutureNode to performs the necessary transformation through the usual emitCodeForFoo:value: messages. (Warning: I have limited knowledge of the inner workings of the Compiler, and so anything I say here might be nonsensical.) frank > Marcus
