What is going on in language part land

[Hamish Rodda]

On Sunday 06 August 2006 02:18, Adam Treat wrote:
> On Saturday 05 August 2006 8:01 am, Jakob Petsovits wrote:
> > On Friday, 4. August 2006 19:00, Adam Treat wrote:
> > > Hi All,
> > >
> > > I just wanted to layout a summary of discussions that are going on with
> > > the parsers.  Roberto was recently in the #kdevelop IRC channel and a
> > > number of us have been talking via email about how to proceed with the
> > > various parsers.
> > >
> > > The current situation:
> > > 1. kdevelop-pg generated C# and Java parsers that do not have a
> > > codemodel. 2. Hand written C++ parser that does have a codemodel, but
> > > one that is lacking.
> > >
> > > Because of the difficulty in coding a codemodel for every language
> > > parser by hand, the thought was to see if kdevelop-pg could be amended
> > > to generate them.
> >
> > For reference, I'm currently working on a generator (about halfway done)
> > that produces codemodels like the current C++ one. I decided to get an
> > exact replication of the C++ codemodel, because I've got no idea how the
> > improved one should look like. But once it's there, we can easily change
> > it to fit our new needs. (Like, referencing the AST instead of storing
> > stuff by itself.)
>
> This might be the way to go.  Just keep the AST as the underlying datastore
> for the codemodel.  The codemodel will just become a bunch of convenience
> functions for developers to manipulate and query the AST.  I like it.
>
> > > Roberto has discussed this in a number of ways.  I think the summary is
> > > that a codemodel is used in addition to the AST for three reasons:
> > >
> > > 1.  Performance and memory usage.  The AST can be resource hungry and
> > > memory intensive.
> > > 2.  The AST does not contain *scope* and *type* information.  The
> > > codemodel does.
> > > 3.  The codemodel's API makes more sense to developers and can be
> > > easier to use and manipulate.
> > >
> > > I made a suggestion that perhaps storing the AST *wouldn't* be such a
> > > huge burden in terms of memory.  If this is so, then perhaps it makes
> > > sense to put aside #1 and see what we can do about #2 and #3.
> > >
> > > #2. is the real bear to me.  I don't know what would be involved with
> > > modifying kdevelop-pg to include scope and type information.  I also
> > > don't know how it would affect the DUChain that Hamish has been working
> > > on.
> >
> > I guess it would be possible to modify kdevelop-pg for including scope
> > and type information, but I would like a more detailed definition of what
> > that information essentially is.
>
> I think Hamish and Roberto might answer this one better.

Well, the DUChain has the scope information, and I think that's the better 
place to store it.  However, the AST could be extended to store pointers to 
DUContexts and Definitions if needed.

For type information, it would be nice to store a pointer to the type object 
in the AST whenever a type is referenced / declared.  This would be filled in 
by a type binding visitor after the AST was created.

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060806/a40d8ae4/attachment.sig>