Re: [jdt-core-dev] Eclipse-conformant parser generator?

[Michael Scharf <Michael-Scharf@xxxxxx>]

Hi,

> I am just asking because I think it would be a great
> strategic advantage vor Eclipse over other IDEs if somebody
> had a tool could generate for any given input grammar a an
> appropriate parser / AST that is automatically
> Eclipse-conformant meaning it would conform to conding
> standards, automatically subclass / implement necessary
> superclasses / interfaces etc. I believe that would make
> thinks like e.g. the current development of the C++ model or
> AspectJ model much easier.

This is one potential solution. However there are other ways
to solve the multi-language problem. In SNiFF+ (written in
C++) we have used a generic AST for all languages. We have
refined this for our eclipse based IDE (with a generic
AST written in Java).

Our browsing tools use this generic AST (outline,
class browser, call tree, import graph etc). To make the
terminology in the tools programming language specific, we
use a "language description file" (LDF) that maps the
generic AST constructs to specific features. For example

feature       C++                       java
------------------------------------------------
include       "include"                 "import"
instvar       "instance variable"       "field"
...


There is additional info in the LDF about how to visualize
the generic AST items in tools. Many tools can be written
using the generic AST, however there are probably some
thing that would be hard to do with a generic AST, like
refactoring etc.

The generic AST is filled using a builder. Parsers use an
API to feed the builder (a library with a simile set of C
calls). Parsers run as external processes and the IDE
receives the AST build constructs via a socket
connection. The advantage of this is, that the parsers can
be written in any language (that supports C binding). It
makes it easy to add ore replace the parser. Parsers cannot
crash the IDE (which can be problematic with in-process
parsers).

The generic AST consists of very few, but wide
interfaces. Because C++ is the most complex language we
support and most other languages can be seen as (or "reduced"
to) a subset of C++. The AST is very C++ like (analogy:
CORBA IDL seems also be "driven" by C++, because C++ is so
rich).

In some way, the generic AST node is like the putting all
CDT AST interfaces into one interface and add a few methods
to generically explore the AST. This might seem confusing at
first, in particular if you are used to deal with specific
AST nodes, however in reality this generic structure allows
you to write tools in a much simpler and a more generic way
and language neutral way.

Here's an analogy: if you deal with XML you can either use a
DOM (generic) or create specific classes representing the
XML data driven bi the schema (DTD, XMLSchema or whatever).

Once you have a generic AST, integration with a debugger
(e.g. gdb) can be done in a language neutral way. You can
use only one configurable editor for all languages,
integrate profiling ad other tools that can deal with
multiple languages....


Michael
--
     ''''\     Michael Scharf
    ` c-@@     Wind River Systems GmbH
    `    >     http://www.WindRiver.com
     \_ V      mailto:Michael.Scharf@xxxxxxxxxxxxx