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
>>>
>>
>>
>
