[Gnome-devtools] Re: Language parser (was: Re: Problems with using CVS)

[Martijn van Beers <martijn earthling net>]

Hi,

[quoting everything so this makes more sense to the people at gnome-devtools]

On Mon, Apr 24, 2000 at 08:38:37PM +0100, David Malcolm wrote:
> I _was_ aiming at quite a simple system... I was going
> to write a base GTK+ class of "parser", with a "C
> parser" derived from it, written using lex and bison. 
> The C parser would emit signals when it encountered
> different lexical and syntactic elements.  You could
> then derive a custom C parser from the base "C parser"
> and, by overriding the signals, "listen" for function
> definitions, variables, etc etc.  You could display
> syntax trees, symbol lists etc.  Other classes could
> be derived for other languages.
> 
> I would also have a standard C parser that would be a
> factory for a syntax tree.  This tree would support a
> "visitor" Design Pattern, letting you express
> traversals of the tree in an object-oriented fashion.
> (in fact, the Design Patterns book uses this precise
> case as its motivating example for "Visitor"!). 
> Manufactured nodes would have file and line
> information in the base class, with derived classes
> for the different language constructs.
> 
> Additionally I would have liked comments to be
> preserved by the parser so that we could generate HTML
> documentation and pop-up/tooltip help from the
> comments using the same internal representation.
> 
> But I've been hampered quite a lot by having left my
> copy of Kernighan & Ritchie at work over Easter and
> can't find a GPL'ed C grammar on the internet!  I've
> got most of the lexer working (from memory). ;-)

Have you looked at starting out from already existing projects? I think
large parts of this problem have been solved already by things like:

lxr
excuberant ctags
cscope

I've been thinking about creating a class browser type thingie
based on lxr. it probably doesn't do all the things neccesary for
a complete class browser, but it does build a nice database
with all the symbols of an application in it, which you can query
from the editor. The reason I picked lxr is that is uses ectags,
and adds cross reference functionality to that. maybe cscope is
a better fit, but I haven't looked at that too thoroughly yet.

> I've just having a look at Harmonia and it looks
> substantially more complicated and sophisticated than
> my approach - and a little scary :-)  My method
> basically isn't "incremental" hence would be SLOW in
> terms of editing support.  But it would be fairly easy
> to maintain.  But I've only been looking ast Harmonia
> for a few minutes so far!

incrementalness would be really neat to support.

> My other thoughts on the matter are having a
> gnorba/Bonobo interface analagous to COM's ITypeLib
> and ITypeInfo, which the editor in Microsoft's Visual
> Studio (and hence Visual C++, Visual Basic et al) uses
> to provide pop-up help, statement completion, method
> listings, "class wizard" functionality etc.  I've been
> reading Microsoft Press's "Inside Distributed COM"
> which explains how it works and gives quite a lot of
> hints as to the internal workings of Visual Studio's
> editor.  A version of such an interface targetting
> GTK+ might be implemented either by parsing the source
> code, or by extracting the classes directly out of a
> library.  In the former case, we would need a
> high-quality parser.  At some point I'll post a
> proposed design of a bonobo interface to this list... 

Maybe the .defs format for gtk+ language bindings are a good
thing to look at for easier class parsing. I think it's better
to try to do as much as possible with the existing infrastructure,
since not everyone likes the idea of an IDE.

There has been talk of creating typelibs for ORBit, not sure if
that will actually take off though.


cya,
Martijn