Hacking inside the compiler instead of extending it to support a good static way of declaring transformations is way to: - make the system more complex, less modular - hamper tools to use a good infrastructure - push hacks and hidden knowledge in all the layers. Definitively not a good idea. This is why opal has a open architecture for plugins. Stef
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? (It's not semantically necessary to have one to support futures; it's a performance enhancer.)
what do you mean by performance enhancer?
Like with ifTrue:, whileTrue: and friends: you can still use futures in Squeak if you don't have FutureNode in your image, but things will just run slower.
frank
frank