http://d-coding.com/2012/05/22/dct-use-cases.html

On Tue, May 22, 2012 at 6:04 PM, Roman D. Boiko <rb@d-coding.com> wrote:

> http://d-coding.com/2012/05/**22/dct-use-cases.html<http://d-coding.com/2012/05/22/dct-use-cases.html>
>

Oh, boy! IMO, that's gonna be THE most useful thing related to D so far.

-- 
Bye,
Gor Gyolchanyan.

On 22.05.2012 18:04, Roman D. Boiko wrote:
> http://d-coding.com/2012/05/22/dct-use-cases.html

>>Find parts of code model by a query (this single point will be >>expanded into its own series of posts)

Love this idea. Some sort of cool hierarchical pattern syntax would save megatons of boilerplate. Efficiency may suffer a bit but we have this CTFE stuff for hardcoded queries ;).

I can easily envision a code transformation of the whole project represented as a bunch of regex-like expressions.

-- 
Dmitry Olshansky

On Tuesday, 22 May 2012 at 14:42:28 UTC, Dmitry Olshansky wrote:
> On 22.05.2012 18:04, Roman D. Boiko wrote:
>> http://d-coding.com/2012/05/22/dct-use-cases.html
>
> >>Find parts of code model by a query (this single point will
> be >>expanded into its own series of posts)
>
> Love this idea. Some sort of cool hierarchical pattern syntax would save megatons of boilerplate. Efficiency may suffer a bit but we have this CTFE stuff for hardcoded queries ;).
>
> I can easily envision a code transformation of the whole project represented as a bunch of regex-like expressions.

The complicated part is conceptual, efficiency is feasible to achieve.

22.05.2012 18:04, Roman D. Boiko написал:
> http://d-coding.com/2012/05/22/dct-use-cases.html

Please, please, try to rape dmd to do what you want first because otherwise you (like every other existing parsers in IDE) will fail with templates which are used everywhere in D (I mean std.algorithm).

A suggestion:
  Step 1 (bad performance): pass whole UTF-8 encoded source to dmd for recompilation every time (through memory mapped file, e.g.) and force dmd to write everything you want (yes, to mmfile because there will be a lot of information).
  Step 2 (better performance): stop dmd at some compilation stage (in a function context) and on user input fork dmd, give it new data, execute it, kill it. Pass whole source only when e.g. user start editing of another function.

It looks like we can't do anything better without good compiler-as-library.


By the way, it was really easy to change dmd to produce token information for token colonizing and it worked faster that Eclipse's Descent IIRC.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On 22.05.2012 18:45, Roman D. Boiko wrote:
> On Tuesday, 22 May 2012 at 14:42:28 UTC, Dmitry Olshansky wrote:
>> On 22.05.2012 18:04, Roman D. Boiko wrote:
>>> http://d-coding.com/2012/05/22/dct-use-cases.html
>>
>> >>Find parts of code model by a query (this single point will
>> be >>expanded into its own series of posts)
>>
>> Love this idea. Some sort of cool hierarchical pattern syntax would
>> save megatons of boilerplate. Efficiency may suffer a bit but we have
>> this CTFE stuff for hardcoded queries ;).
>>
>> I can easily envision a code transformation of the whole project
>> represented as a bunch of regex-like expressions.
>
> The complicated part is conceptual, efficiency is feasible to achieve.

Well for starters:

Abuse regex syntax, ban '/' w/o escape & use '/' for scopes/level, introduce a bunch of better wildcards/character sets like "identifier" etc. Throw in annotations that work like a list of tags the symbol should(n't) have: constant, template, function, class, struct, ... see traits. Same goes for protection & other annotations.

Then it goes like:

demo/{function, pure}f.*/i
->
j
(e.g. simple rename, refactoring looks similarly)

To fetch all of local symbols named i inside of pure functions that begin with 'f' inside entity demo  (entity = struct, class, template, module depending on where you apply it) and rename them to j.

I suggest to go with such kind of improvised notation with more examples until you fell that semantics are crystal clear.


-- 
Dmitry Olshansky

On Tuesday, 22 May 2012 at 14:48:49 UTC, Denis Shelomovskij wrote:
> 22.05.2012 18:04, Roman D. Boiko написал:
>> http://d-coding.com/2012/05/22/dct-use-cases.html
>
> Please, please, try to rape dmd to do what you want first because otherwise you (like every other existing parsers in IDE) will fail with templates which are used everywhere in D (I mean std.algorithm).
>
> A suggestion:
>   Step 1 (bad performance): pass whole UTF-8 encoded source to dmd for recompilation every time (through memory mapped file, e.g.) and force dmd to write everything you want (yes, to mmfile because there will be a lot of information).
>   Step 2 (better performance): stop dmd at some compilation stage (in a function context) and on user input fork dmd, give it new data, execute it, kill it. Pass whole source only when e.g. user start editing of another function.
>
> It looks like we can't do anything better without good compiler-as-library.
>
>
> By the way, it was really easy to change dmd to produce token information for token colonizing and it worked faster that Eclipse's Descent IIRC.

Thanks, but what you described is outside DCT scope and goals.

On Tuesday, 22 May 2012 at 14:48:49 UTC, Denis Shelomovskij wrote:
> 22.05.2012 18:04, Roman D. Boiko написал:
>> http://d-coding.com/2012/05/22/dct-use-cases.html
>
> Please, please, try to rape dmd to do what you want first because otherwise you (like every other existing parsers in IDE) will fail with templates which are used everywhere in D (I mean std.algorithm).
>
> A suggestion:
>   Step 1 (bad performance): pass whole UTF-8 encoded source to dmd for recompilation every time (through memory mapped file, e.g.) and force dmd to write everything you want (yes, to mmfile because there will be a lot of information).
>   Step 2 (better performance): stop dmd at some compilation stage (in a function context) and on user input fork dmd, give it new data, execute it, kill it. Pass whole source only when e.g. user start editing of another function.
>
> It looks like we can't do anything better without good compiler-as-library.
>
>
> By the way, it was really easy to change dmd to produce token information for token colonizing and it worked faster that Eclipse's Descent IIRC.

Thanks, but what you described is outside DCT scope and goals.

On Tuesday, 22 May 2012 at 14:56:42 UTC, Dmitry Olshansky wrote:
> On 22.05.2012 18:45, Roman D. Boiko wrote:
>> On Tuesday, 22 May 2012 at 14:42:28 UTC, Dmitry Olshansky wrote:
>>> On 22.05.2012 18:04, Roman D. Boiko wrote:
>>>> http://d-coding.com/2012/05/22/dct-use-cases.html
>>>
>>> >>Find parts of code model by a query (this single point will
>>> be >>expanded into its own series of posts)
>>>
>>> Love this idea. Some sort of cool hierarchical pattern syntax would
>>> save megatons of boilerplate. Efficiency may suffer a bit but we have
>>> this CTFE stuff for hardcoded queries ;).
>>>
>>> I can easily envision a code transformation of the whole project
>>> represented as a bunch of regex-like expressions.
>>
>> The complicated part is conceptual, efficiency is feasible to achieve.
>
> Well for starters:
>
> Abuse regex syntax, ban '/' w/o escape & use '/' for scopes/level, introduce a bunch of better wildcards/character sets like "identifier" etc. Throw in annotations that work like a list of tags the symbol should(n't) have: constant, template, function, class, struct, ... see traits. Same goes for protection & other annotations.
>
> Then it goes like:
>
> demo/{function, pure}f.*/i
> ->
> j
> (e.g. simple rename, refactoring looks similarly)
>
> To fetch all of local symbols named i inside of pure functions that begin with 'f' inside entity demo  (entity = struct, class, template, module depending on where you apply it) and rename them to j.
>
> I suggest to go with such kind of improvised notation with more examples until you fell that semantics are crystal clear.

This is a possible, although not the only, option. Anyway I'm not
ready for designing the details yet. There is a lot to do before
that.

On Tuesday, 22 May 2012 at 15:15:49 UTC, Roman D. Boiko wrote:
> On Tuesday, 22 May 2012 at 14:56:42 UTC, Dmitry Olshansky wrote:
>> I suggest to go with such kind of improvised notation with more examples until you fell that semantics are crystal clear.
>
> This is a possible, although not the only, option. Anyway I'm not
> ready for designing the details yet. There is a lot to do before
> that.

After thinking a bit more, I decided to investigate the topic
early, although not immediately :) It should help deciding which
indices are needed, where are rough edges of API, etc.