www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Lang.NEXT panel

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Of possible interest. 
http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/

Andrei
Jun 03 2014
next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu 
wrote:

 Of possible interest. 
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/

 Andrei


Nice panel.  Not much really new there, but gives an idea of what 
you language designers are thinking about and who you are.  I was 
never much interested in Go, but after seeing Pike for the first 
time, was a bit more interested in his language.  Funny to see 
Bjarne swinging his legs on the high stool like a kid. :)
Jun 04 2014
prev sibling parent reply "justme" <justme example.com> writes:
On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu 
wrote:

 Of possible interest. 
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/

 Andrei


IMHO, the coolest thing was when Rob Pike told about the tool 
they made for automatically upgrading user source code to their 
next language version.

That should be quite easy to implement now in D, and once done, 
would give much needed room for breaking changes we feel should 
be done. Pike seemed to be extremely satisfied they did it.
Jun 10 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/10/2014 12:35 PM, justme wrote:

 On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:

 Of possible interest.
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/


 Andrei


 IMHO, the coolest thing was when Rob Pike told about the tool they made
 for automatically upgrading user source code to their next language
 version.

 That should be quite easy to implement now in D, and once done, would
 give much needed room for breaking changes we feel should be done. Pike
 seemed to be extremely satisfied they did it.


Personally, I wouldn't be comfortable trusting such a tool. Besides, I 
find that upgrading a codebase to a newer language version is one of the 
most trivial tasks I ever face in software development - even in D.

It's a cute trick, but not a worthwhile use of development resources.
Jun 12 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/12/14, 10:40 AM, Nick Sabalausky wrote:

 On 6/10/2014 12:35 PM, justme wrote:

 On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:

 Of possible interest.
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/



 Andrei


 IMHO, the coolest thing was when Rob Pike told about the tool they made
 for automatically upgrading user source code to their next language
 version.

 That should be quite easy to implement now in D, and once done, would
 give much needed room for breaking changes we feel should be done. Pike
 seemed to be extremely satisfied they did it.


 Personally, I wouldn't be comfortable trusting such a tool. Besides, I
 find that upgrading a codebase to a newer language version is one of the
 most trivial tasks I ever face in software development - even in D.

 It's a cute trick, but not a worthwhile use of development resources.


I very much think the opposite, drawing from many years of hacking into 
large codebases. I'm completely with Rob here. On a large codebase, even 
the slightest manual or semi-manual change is painstaking to plan and 
execute, and almost always suffers of human errors.

I got convinced a dfix tool would be a strategic component of D's 
offering going forward.


Andrei
Jun 12 2014
next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu 
wrote:

 On 6/12/14, 10:40 AM, Nick Sabalausky wrote:

 On 6/10/2014 12:35 PM, justme wrote:

 On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei 
 Alexandrescu wrote:

 Of possible interest.
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/



 Andrei


 IMHO, the coolest thing was when Rob Pike told about the tool 
 they made
 for automatically upgrading user source code to their next 
 language
 version.

 That should be quite easy to implement now in D, and once 
 done, would
 give much needed room for breaking changes we feel should be 
 done. Pike
 seemed to be extremely satisfied they did it.


 Personally, I wouldn't be comfortable trusting such a tool. 
 Besides, I
 find that upgrading a codebase to a newer language version is 
 one of the
 most trivial tasks I ever face in software development - even 
 in D.

 It's a cute trick, but not a worthwhile use of development 
 resources.


 I very much think the opposite, drawing from many years of 
 hacking into large codebases. I'm completely with Rob here. On 
 a large codebase, even the slightest manual or semi-manual 
 change is painstaking to plan and execute, and almost always 
 suffers of human errors.

 I got convinced a dfix tool would be a strategic component of 
 D's offering going forward.


 Andrei


I thought the same. I was considering writing it, actually. 
Imagine how having the tool would have influenced the "final by 
default" discussion. Amongst others, of course.

Atila
Jun 12 2014
prev sibling next sibling parent John Carter via Digitalmars-d-announce writes:
Yes!

That is only one of the reasons to have that ability.

Almost more important is automated reasoning about very large codebases.

What are the global properties?

Where are the "antipatterns" of use and can we fix them?

Can we "lint" away large classes of defects?

Even Stroustrup believes such tools would be useful for C++.


On Fri, Jun 13, 2014 at 5:53 AM, Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:


 On 6/12/14, 10:40 AM, Nick Sabalausky wrote:


 On 6/10/2014 12:35 PM, justme wrote:


 On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:


 Of possible interest.
 http://www.reddit.com/r/programming/comments/278twt/
 panel_systems_programming_in_2014_and_beyond/



 Andrei


 IMHO, the coolest thing was when Rob Pike told about the tool they made
 for automatically upgrading user source code to their next language
 version.

 That should be quite easy to implement now in D, and once done, would
 give much needed room for breaking changes we feel should be done. Pike
 seemed to be extremely satisfied they did it.


 Personally, I wouldn't be comfortable trusting such a tool. Besides, I
 find that upgrading a codebase to a newer language version is one of the
 most trivial tasks I ever face in software development - even in D.

 It's a cute trick, but not a worthwhile use of development resources.


 I very much think the opposite, drawing from many years of hacking into
 large codebases. I'm completely with Rob here. On a large codebase, even
 the slightest manual or semi-manual change is painstaking to plan and
 execute, and almost always suffers of human errors.

 I got convinced a dfix tool would be a strategic component of D's offering
 going forward.


 Andrei



-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand

-- 

------------------------------
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
------------------------------
Jun 12 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu 
wrote:

 I very much think the opposite, drawing from many years of 
 hacking into large codebases. I'm completely with Rob here. On 
 a large codebase, even the slightest manual or semi-manual 
 change is painstaking to plan and execute, and almost always 
 suffers of human errors.

 I got convinced a dfix tool would be a strategic component of 
 D's offering going forward.


It essentially comes down to persistent compiler-as-a-library 
issue :( Tools like dscanner can help with some of more simple 
transition cases but anything more complicated is likely to 
require full semantic analysis.
Jun 12 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 12 June 2014 at 20:48:10 UTC, Dicebot wrote:

 On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu 
 wrote:

 I very much think the opposite, drawing from many years of 
 hacking into large codebases. I'm completely with Rob here. On 
 a large codebase, even the slightest manual or semi-manual 
 change is painstaking to plan and execute, and almost always 
 suffers of human errors.

 I got convinced a dfix tool would be a strategic component of 
 D's offering going forward.


 It essentially comes down to persistent compiler-as-a-library 
 issue :( Tools like dscanner can help with some of more simple 
 transition cases but anything more complicated is likely to 
 require full semantic analysis.


If only we had such a tool !
Jun 12 2014
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Thursday, 12 June 2014 at 17:52:59 UTC, Andrei Alexandrescu 
wrote:

 On 6/12/14, 10:40 AM, Nick Sabalausky wrote:

 On 6/10/2014 12:35 PM, justme wrote:

 On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei 
 Alexandrescu wrote:

 Of possible interest.
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/



 Andrei


 IMHO, the coolest thing was when Rob Pike told about the tool 
 they made
 for automatically upgrading user source code to their next 
 language
 version.

 That should be quite easy to implement now in D, and once 
 done, would
 give much needed room for breaking changes we feel should be 
 done. Pike
 seemed to be extremely satisfied they did it.


 Personally, I wouldn't be comfortable trusting such a tool. 
 Besides, I
 find that upgrading a codebase to a newer language version is 
 one of the
 most trivial tasks I ever face in software development - even 
 in D.

 It's a cute trick, but not a worthwhile use of development 
 resources.


 I very much think the opposite, drawing from many years of 
 hacking into large codebases. I'm completely with Rob here. On 
 a large codebase, even the slightest manual or semi-manual 
 change is painstaking to plan and execute, and almost always 
 suffers of human errors.

 I got convinced a dfix tool would be a strategic component of 
 D's offering going forward.


 Andrei


I am strongly in favour of a 'dfix' tool. There exist historical 
problems with languages, and you really must break them to make 
things better.

Douglas Crockford was pushing for '~' for string concatenation in 
ECMAScript 6, making '+' do only additon. This would have been 
very similar to how D handles the two, in an arguably correct 
manner, but the commity wouldn't agree to it because it would 
force everyone to change their code. So in the end ES6 is full of 
features, some useful, most seem nonsensical to me, but it 
doesn't really fix any of the issues in ES5, because it's almost 
totally backwards compatible so old code still works.

So I think having tools like gofix and deprecation warnings 
mitigate this issue massively, and it's especially easier when 
you're using an ahead-of-time compiled language like D. So we can 
make changes which break code, but just get rid of cruft likely 
to cause errors. I can't think of nearly as many examples of 
error-prone things in D that I can think of in ES6, though.
Jun 12 2014
parent "Stefan Koch" <uplink.coder gmail.com> writes:
As it happens I am writing a kind of DFIX  on top of DScanner 
right at the moment.
There are a few details to sort out. But I should have some small 
demo pretty soon.

Regrards, Stefan
Jun 14 2014
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 12/06/2014 18:53, Andrei Alexandrescu wrote:

 On 6/12/14, 10:40 AM, Nick Sabalausky wrote:

 On 6/10/2014 12:35 PM, justme wrote:

 On Wednesday, 4 June 2014 at 06:13:39 UTC, Andrei Alexandrescu wrote:

 Of possible interest.
 http://www.reddit.com/r/programming/comments/278twt/panel_systems_programming_in_2014_and_beyond/




 Andrei


 IMHO, the coolest thing was when Rob Pike told about the tool they made
 for automatically upgrading user source code to their next language
 version.

 That should be quite easy to implement now in D, and once done, would
 give much needed room for breaking changes we feel should be done. Pike
 seemed to be extremely satisfied they did it.


 Personally, I wouldn't be comfortable trusting such a tool. Besides, I
 find that upgrading a codebase to a newer language version is one of the
 most trivial tasks I ever face in software development - even in D.

 It's a cute trick, but not a worthwhile use of development resources.


 I very much think the opposite, drawing from many years of hacking into
 large codebases. I'm completely with Rob here. On a large codebase, even
 the slightest manual or semi-manual change is painstaking to plan and
 execute, and almost always suffers of human errors.

 I got convinced a dfix tool would be a strategic component of D's
 offering going forward.


 Andrei


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)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 16 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/14, 6:43 AM, Bruno Medeiros wrote:

 On 12/06/2014 18:53, Andrei Alexandrescu wrote:

 I got convinced a dfix tool would be a strategic component of D's
 offering going forward.


 Andrei


 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)


No magic required. -- Andrei
Jun 16 2014
prev sibling next sibling parent reply "Stefan Koch" <uplink.coder gmail.com> writes:
 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.
Jun 16 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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
Jun 16 2014
parent reply "Stefan Koch" <uplink.coder gmail.com> writes:
 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.


The thing I have in mind should be really easy for simple tasks
as in
`if constuctor in any class has parameter of type "oldRouter" 
change that parameter to type "new Router"`
but i habe yet to find a good notation for that
Jun 16 2014
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 16/06/2014 22:10, Stefan Koch wrote:

 The thing I have in mind should be really easy for simple tasks
 as in
 `if constuctor in any class has parameter of type "oldRouter" change
 that parameter to type "new Router"`
 but i habe yet to find a good notation for that


I guess a DSL for simple manipulations can be ok to have. But for more 
complex stuff better to just use the language the parser is written in.
I'd guess most people would just be using pre-written manipulations anyways.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 17 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 16/06/14 15:43, Bruno Medeiros 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)


* The parser haven't been available for that long (I think)
* Can they handle whole language?
* Semantic analysis is needed. Otherwise as soon as someone uses 
templates or mixins the tool won't properly work

-- 
/Jacob Carlborg
Jun 16 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/06/2014 07:25, Jacob Carlborg wrote:

 On 16/06/14 15:43, Bruno Medeiros 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)


 * The parser haven't been available for that long (I think)
 * Can they handle whole language?


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)


 * Semantic analysis is needed. Otherwise as soon as someone uses
 templates or mixins the tool won't properly work


I think there would be a lot of modifications that one can do without 
semantic analysis (or limited analysis). But that's why I asked for 
examples of dfix scenarios.

Adding "final" to every method in certain classes could be done without 
semantic analysis. Reworking certain constructs to different constructs 
possibly as well (for example change foreach_reverse to just foreach usage)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 17 2014
next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/06/2014 16:45, 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)


And DDT is fairly complete, AFAIK, and well covered in tests. There 
might be some syntax I have missed if I misunderstood the grammar, but 
that should be fixable easily.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 17 2014
prev sibling next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/06/2014 16:45, Bruno Medeiros wrote:

 Similarly, there is also DParser2 from MonoD and the DDT parser (for the
 tool I'm working on)


And the DDT parser is fairly complete, AFAIK, and well covered in tests. 
There might be some syntax I have missed if I misunderstood the grammar 
spec, but that should be fixable easily.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 17 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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).


 * Semantic analysis is needed. Otherwise as soon as someone 
 uses
 templates or mixins the tool won't properly work


 I think there would be a lot of modifications that one can do 
 without semantic analysis (or limited analysis). But that's why 
 I asked for examples of dfix scenarios.


Until you hit a static if. Which is always.


 Adding "final" to every method in certain classes could be done 
 without semantic analysis. Reworking certain constructs to 
 different constructs possibly as well (for example change 
 foreach_reverse to just foreach usage)


ditto.
Jun 17 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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?


 * Semantic analysis is needed. Otherwise as soon as someone uses
 templates or mixins the tool won't properly work


 I think there would be a lot of modifications that one can do without
 semantic analysis (or limited analysis). But that's why I asked for
 examples of dfix scenarios.


 Until you hit a static if. Which is always.


 Adding "final" to every method in certain classes could be done
 without semantic analysis. Reworking certain constructs to different
 constructs possibly as well (for example change foreach_reverse to
 just foreach usage)


 ditto.


How would a static if prevent a tool from adding "final" to every method 
in a specified class?


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 17 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jun 17 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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
Jun 20 2014
parent "Dicebot" <public dicebot.lv> writes:
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 :(
Jun 20 2014
prev sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Tuesday, 17 June 2014 at 15:45:55 UTC, Bruno Medeiros wrote:


 Adding "final" to every method in certain classes could be done 
 without semantic analysis. Reworking certain constructs to 
 different constructs possibly as well (for example change 
 foreach_reverse to just foreach usage)


What about methods added via template and string mixins? You 
cannot add "final" to a method in a template, because you don't 
know if it will be mixed in into a class or struct (does the 
compiler allow "final" on struct methods?). There's no possible 
way to handle string mixins, a method can be built up by 
concatenating strings.

--
/Jacob Carlborg
Jun 17 2014
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 17/06/2014 20:12, Jacob Carlborg wrote:

 On Tuesday, 17 June 2014 at 15:45:55 UTC, Bruno Medeiros wrote:


 Adding "final" to every method in certain classes could be done
 without semantic analysis. Reworking certain constructs to different
 constructs possibly as well (for example change foreach_reverse to
 just foreach usage)


 What about methods added via template and string mixins? You cannot add
 "final" to a method in a template, because you don't know if it will be
 mixed in into a class or struct (does the compiler allow "final" on
 struct methods?). There's no possible way to handle string mixins, a
 method can be built up by concatenating strings.

 --
 /Jacob Carlborg


Methods added through string mixins would not work. Actually, any AST 
modification would probably not work through string mixins. That would 
be an incredibly difficult problem to solve - in many cases, impossible 
even.
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.

As for methods added via templates, the tool would present the option to 
add "final" to those templates as well, or just the class. If doing do 
might break other classes that use the same template, well, that is a 
problem that transcends whether this transformation is done manually or 
by a tool. It would not be an issue with "dfix" itself then.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jun 17 2014
parent reply Jacob Carlborg <doob me.com> writes:
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 ;)

-- 
/Jacob Carlborg
Jun 17 2014
next sibling parent reply "Stefan Koch" <uplink.coder gmail.com> writes:
On Wednesday, 18 June 2014 at 06:43:32 UTC, 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 ;)


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
Jun 19 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
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
Jun 19 2014
parent "Stefan Koch" <uplink.coder gmail.com> writes:
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.
Jun 20 2014
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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
Jun 20 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 12/06/14 19:40, Nick Sabalausky wrote:


 Personally, I wouldn't be comfortable trusting such a tool. Besides, I
 find that upgrading a codebase to a newer language version is one of the
 most trivial tasks I ever face in software development - even in D.

 It's a cute trick, but not a worthwhile use of development resources.


I think the complete opposite. I migrated a Rails 2.3 app to Rails 3.x 
and from Ruby 1.8 to 1.9, it was an enormous task. Took probably six 
months. Also, it doesn't help to not have any tests and Ruby code in the 
database.

-- 
/Jacob Carlborg
Jun 12 2014
prev sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 10 June 2014 at 16:35:23 UTC, justme wrote:

 That should be quite easy to implement now in D


What makes you say this?
Jun 12 2014