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

["Scott Stanchfield" <scott@xxxxxxxxxxxx>]

Sounds pretty reasonable... I'd agree that C++ is about as nasty as a
language can get. (I was on the ANSI committee, but only for the last two
meetings -- don't blame me, I voted "no, with comments" ;)

I can think of a few problems "promoting" everything to a C++ like AST. One
is potential bloat. I'm not sure how you implemented things, but in the past
I've seen C++ "catch all" models that are pretty heavy due to the
requirements of dealing with C++ (much of it symbol table bloat). Of course
with more and more RAM available, that issue becomes less of an impact.

Another problem might be a good mapping. Many languages will map very well
(most of the current 3GLs are pretty similar in structure), but some may
lose fidelity. I don't know how many of these there are (or will be), but
just something to consider. Probably not many right now.

Of course having a common model does make several integration concerns much
easier, not to mention makes it way easier to ensure lots of parts are
"right". I get the feeling this may need changes in many tools (like the
debugger) to allow language-specific plugins that could allow extra detail
to be added based on the capabilities of some languages.


The big issue in my mind is licensing. SNiFF+ is commercial, right? Would
y'all be interested in open sourcing the base integration models? This would
allow new languages to be added free to eclipse, while making availability
of SNiFF+'s analysis almost free for any of those new languages.

If the language project team likes what you've got, and the right licensing
situation could be arranged, this could be a win for all of us... So far,
the chat has been about creating a framework that would make creation of
language additions easier. That's more flexible, but can involve more work
than a common model like y'all have got.

My 2c...
-- Scott


> -----Original Message-----
> From: jdt-core-dev-admin@xxxxxxxxxxx 
> [mailto:jdt-core-dev-admin@xxxxxxxxxxx] On Behalf Of Michael Scharf
> Sent: Monday, January 26, 2004 11:58 AM
> To: jdt-core-dev@xxxxxxxxxxx
> Subject: Re: [jdt-core-dev] Eclipse-conformant parser generator?
> 
> 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
> 
> 
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
> 
> 
>