Re: [cdt-dev] Ada in CDT

[kesselhaus@xxxxxxx]

> 
> On Apr 22, 2005, at 5:53 AM, Douglas Schaefer wrote:
> 
> > What I want to see is whether our DOM is extensible enough to handle
> > additional, not so C-like, languages. We already have extensions for 
> > ANSI
> > C and C++ and then into GNU C and C++. I know Ada enough to give it a 
> > try
> > and see. The follow on step would be ICElement and friends which I 
> > would
> > create from the results of a DOM quick parse. Finally, we would have 
> > the
> > index which would be populated by gnatxref which is a ctags kind of 
> > thing
> > that also has cross reference info and should be enough to satisfy our
> > search engine.
> >
> > The dream is that, if you can extend the DOM and ICElement and index 
> > for
> > your particular language, then you would get the content assist and
> > navigation features for free, or as free as the gdb integration seems 
> > to
> > be ;). I'm a long way from seeing whether the dream comes true, though.
> 
> I think the dream may be possible.  However, the only datapoint I have 
> is
> with a project that uses XML to describe C/C++ and Fortran interfaces 
> (function
> names and parameter types.  This meant we had to be able to map the 
> language type
> systems to XML.  It turned out that C and Fortran share a lot in common 
> so this
> effort went very smoothly.

It's just a thought out of reading this. Why not use an XMI-style format,
maybe based on EMF?


> On Apr 21, 2005, at 8:26 PM, Jeffrey Overbey wrote:
> 
> > If our entire AST needs to comply with some CDT interfaces, um... I 
> > haven't counted, but this thing is on the order of 400-500 
> > classes/interfaces, and I don't have all that much interest in 
> > changing every one of them.  :-)  But you might convince us
> 
> I've met this week with some colleagues at the University of Oregon who 
> do static analysis
> to instrument user code with performance counters.  They have recently 
> created a Java
> plugin to demonstrate the concept using the JST DOM to add a node in 
> the AST and then
> unparse to a new file (with performance instrumentation).  The goal is 
> to try the same thing
> with the CDT DOM and then move on to the Photran AST.
> 
> I think the question will be is how much different the Photran AST (and 
> API) is from the DOM.
> I think it may turn out that it will be useful to move the Photran AST 
> to be more compatible
> with the DOM.  It so, then perhaps we at LANL could help.

Btw., do you think someone could make up some docs about how to enter into
the DOM. I'm trying hard to understand the Eclipse-Plugin stuff, and how to
hook up something into CDT. Some docs on how to enter the DOM and what could
be retrieved would be nice (even though, you guys should document your
CDT-source more thoroughly anyway). Most people outside the CDT-core team do
not have your inside knowledge on what classes/methods do just by reading
its names.

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++

10 GB Mailbox, 100 FreeSMS  http://www.gmx.net/de/go/topmail