Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Ada in CDT

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.

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.


Back to the top