On Thursday, 19 June 2014 at 20:37:48 UTC, Stefan Koch wrote:
> hmm well all string-mixins life at compile-time so one can print them out at runtime dump the source and but it into the ast same for the results of static if and the like

I imagine that trying to create an automated refactoring tool for D is a bit like parsing HTML with regex.

http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

On Thursday, 19 June 2014 at 21:28:28 UTC, Brian Schott wrote:
> On Thursday, 19 June 2014 at 20:37:48 UTC, Stefan Koch wrote:
>> hmm well all string-mixins life at compile-time. So one can print them out at runtime. Dump the source and put it into the AST. Same for the results of static if, and the like.
>
> I imagine that trying to create an automated refactoring tool for D is a bit like parsing HTML with regex.
>
> http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

A hypothetical dfix-tool has a diffrent scope compared to a compiler.
Every sufficiently complex tranformation is very hard to do automaticlly.
My goal is just to make simple tasks simple. I hope superficial understanding of D's AST is enough for that.

On 18/06/2014 07:43, Jacob Carlborg wrote:
> On 17/06/14 22:00, Bruno Medeiros wrote:
>
>> And perhaps rightly so, one could make a case that string mixins should
>> be used sparsely? We have to realize that string mixins are very useful,
>> but are a dirty hack that is a replacement for AST macros.
>
> I fully agree, but that won't stop anyone from actually using string
> mixins ;)
>

Well, that's acceptable: the tool could just print a warning when it finds strings mixins that it can't understand. I think the tool doesn't necessarily have to work on 100% of cases to be useful. If it can work correctly on the changes that it does do, and print a warning to the user to manually change/check the other remaining spots, it should still be useful.

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

On 17/06/2014 20:59, Dicebot wrote:
> On Tuesday, 17 June 2014 at 19:48:42 UTC, Bruno Medeiros wrote:
>> On 17/06/2014 19:10, deadalnix wrote:
>>> On Tuesday, 17 June 2014 at 15:45:55 UTC, Bruno Medeiros wrote:
>>>
>>>> Dunno about DScanner, but if it's being used in DCD, I'd guess it can
>>>> handle the whole language, or be fairly close to it.
>>>>
>>>> Similarly, there is also DParser2 from MonoD and the DDT parser (for
>>>> the tool I'm working on)
>>>>
>>>
>>> HAHAHAHAHAHA ! (The author of these actual tools will tell you the
>>> same).
>>>
>>
>> I don't understand what point is it you're trying to say here...
>> Are you saying it's ludicrous that people have written complete
>> parsers for D?
>
> Parsing D is relatively simple but making any reliable changes without
> full (and mean _full_) semantic analysis is close to impossible because
> of code generation and interleaving semantic stages.

A lot of simple changes could be made with little or no semantic analysis. I'm not talking about complex refactorings such as Extract/Inline Function, Introduce/Remove Parameter, Pull Method Up/Down, extract Class/Interface, etc.

Rather, simple fix changes that would be useful if the API or syntax of the language changes. That's why I asked for examples of dfix changes (even if for hypothetical language changes) - to see how easily they could be implemented or not.

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

On Friday, 20 June 2014 at 13:04:23 UTC, Bruno Medeiros wrote:
> Rather, simple fix changes that would be useful if the API or syntax of the language changes. That's why I asked for examples of dfix changes (even if for hypothetical language changes) - to see how easily they could be implemented or not.

Well I guess most recent example is that `final` by default proposal - marking all existing functions as virtual ones explicitly.

Problem with dfix is that such tool can't afford to be "best effort" implementation if it is to be used as justification for breaking changes. It needs to provide guaranteed 0-cost transition or someone will be inevitably unhappy about the breakage anyway :(