dparser 0.148 something concrete attn: Ben Hinkle

[AgentOrange]

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?