[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [jdt-core-dev] Eclipse-conformant parser generator?
|
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
>
>
>