Lang.NEXT panel (dfix)

[Bruno Medeiros via Digitalmars-d-announce]

On 16/06/2014 21:43, Stefan Koch wrote:
>> What's keeping us from having such a tool? It seems that after one has
>> a decent parser (that also keeps tracks of the source ranges of AST
>> nodes), it's easy to write code that does syntactic modifications and
>> then rewrites the source code. And there's several D parsers out there
>> already - so it should be too much effort to get there.
>> Even I am working on a tool that can be easily retrofitted for this
>> purpose.
>>
>> Or maybe I am misunderstanding the amount of semantic analysis that
>> would typically be required? Can someone give some examples of
>> modifications that would be useful for such a dfix tool? (I haven't
>> yet had the time to watch the full panel video, if that's relevant)
>
> Well, my recent efforts lead my to belief that I am in over my head with
> this.
> But ... many sufficiently simple transformations can be done with a
> complex regex and for me that is faster, given the trouble I have with
> writing ASTMatchers for Dscanner.
> BTW. Does anyone know a good approch to a DSL describeing
> AST-transformation patterns ?
> What I currently have is SQL-like Syntax and I feel it won't scale to
> complex  selction and/or transformation patterns.
> Input is welcome.

DSL?! You crazy bro?
If you are using DScanner, just let people use D itself to write their 
own custom AST transformation code. With DUB it should be super easy to 
compile that code and run it on the target D code.

This solution is vastly more simple than inventing your own DSL, and 
scales way better as a general purpose language will have much more 
power that selection/transformation patterns.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros