dparser 0.148 something concrete attn: Ben Hinkle

[pragma]

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