dparser 0.148 something concrete attn: Ben Hinkle

[AgentOrange]

In article <du9jar$2scq$1 at digitaldaemon.com>, pragma says...
>
>In article <du4l8c$16mh$1 at digitaldaemon.com>, AgentOrange says...
>>
>>In article <du4ipa$135d$1 at digitaldaemon.com>, bls says...
>>>
>>>
>>>bobef :
>>>> Seems that there are currently three IDEs for D in development (your 
>>>> one, Poseidon, akide) that needs the above features. Maybe we don't need 
>>>> to do this work three times?
>>>
>>>Indeed! Just forgot to mention that Ben Hinkle allready has enhanced the 
>>>dmd frontend with stubs. (in C++). Unfortunately Ben offers not much 
>>>intro-material. Hint. Hint....
>>>Björn
>>
>>Ive been thinking about this, but A major difference between dmdfe in C++ and
>>dparser in D is that 'stub' class methods cant be broken out of the class module
>>into a seperate file. hes got all the stubs in one place... I think I could
>>mangle some identifiers to do it, or just implement some sort of external
>>callback system with global functions or delegates.... If anyone has a clean
>>solution to this Id love to hear it....
>>
>>And yes one of the reasons Ive done this is to support a whole range of D tools,
>>including an IDE/debugger Im working with. Id like to have some sort of clean
>>interface for higher level tools which dont need to deal with the internals for
>>dparser. I chose using the front end because it can easily be kept current to
>>the language just by following diffs between dmd releases, It also offers a rich
>>symbol and object heirarchy (ast) which a simple lexer parser doesnt. It also
>>lends itself well to experimenting with the languge, which ive recently begun
>>playing with now that dparser is updated (for example the new scope guards are
>>just symbols that rewrite themselves as try..catch blocks). I currently just
>>access dparser DSymbols etc in my code, but Im thinking of creating some sort of
>>independent class hierarchy which dparser can generate. This secondary symbol
>>hierarchy could be used in tools such as IDEs and class browsers and wouldnt
>>have to cary around parse and semantic analysis code. (it might even be useful
>>for reflection;)..... Any ideas?
>
>I, for one, would love to use dparser to generate better DDOC output; especially
>for cross-references and class-tree diagram generation.  Your work seems to get
>the job mostly done, but it's unclear how to hook into the DDOC generation parts
>(they seem to be mostly commented out).
>
>As for a clean solution for hooking into dparser, I think you're on the right
>track with the class/symbol tree.  It would be by far the most useful
>representation of what the compiler generates.  The current lookup scheme (that
>was added on for the IDE) seems usable enough, but its difficult knowing where
>to start.  Reducing the entire scheme to "get me the class tree for this source
>file" would be a godsend. :)
>
>- EricAnderton at yahoo

I agree, its pretty raw still and mostly unusable unless you know the dmd front
end. I added those symbollistings from poseidon just for the heck of it. But my
main goal up till now was to get the parser up to date with the current
compiler. Ive been kind of afraid to touch it until I had it updated because of
the way ive managed converting the code. But Ive done some extensive testing
lately with parsing then generating code and verifying binaries are identicle,
which has been successfull. Yes I have completely avoided ddoc until this point,
but my next goal is to get ddoc.c converted to D and then I will work out an
interface for dparser. Yeah there has been some discussions around #D about docs
and someone even mentioned going back to doxygen (shudder), so I figure a ddoc
implementation we can get our hands dirty with can be pretty usefull......