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

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

Reply via email to