Re: [cdt-dev] Re: CDT Parsing Callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [cdt-dev] Re: CDT Parsing Callback

From: "John Camelon" <jcamelon@xxxxxxxxxx>
Date: Tue, 6 May 2003 19:41:57 -0400
Delivered-to: cdt-dev@xxxxxxxxxxx
List-archive: <http://dev.eclipse.org/pipermail/cdt-dev/>
List-help: <mailto:cdt-dev-request@eclipse.org?subject=help>
List-subscribe: <http://dev.eclipse.org/mailman/listinfo/cdt-dev>, <mailto:cdt-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <http://dev.eclipse.org/mailman/listinfo/cdt-dev>, <mailto:cdt-dev-request@eclipse.org?subject=unsubscribe>

Cool Alain, I just wanted to know my features up front. :-)

I am unsure as to why you believe that we do not need to parse function bodies in order to provide the search feature. Searching for references is the meat of the overall feature, in my opinion.

Anyway, currently our parser is not structured in a way that makes the type of callback you are talking about simple. We do not maintain an AST, so there are no "function" objects that we can pass into a requestor. However, that is a direction we are thinking about going, since between the DOM (outside the parser) and the symbol table (inside the parser), we could have the equivalent of a full AST given a bit of refactoring. Also, the further into the C++ grammar I get, the more ambiguities I discover, and I think it is becoming clear that the cost of backtracking out of ambiguous decisions is much more difficult to do from multiple clients. We are currently analyzing the pros and cons of moving to an AST solution.

I am interested in providing a dead-accurate search much like the JDT; however, C++ is seriously more complex regarding how references and names are resolved at compile time ( function overloading, implicit casts, user defined conversion operators, template specializations and implicit instantiations) and there is a lot of work to be done here on the parser side. If you have any ideas on what you would like a new callback interface to look like, feel free to send it to me, or maybe we could meet later this week to try and make sure that your indexer work is not held up by these parser work-items.

Cheers,
JohnC

"Alain Magloire" <alain@xxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

05/06/2003 05:15 PM
Please respond to cdt-dev

To: cdt-dev@xxxxxxxxxxx
cc:
Subject: Re: [cdt-dev] Re: CDT Parsing Callback

> > This is a multipart message in MIME format. > --=_alternative 0071003D85256D1E_= > Content-Type: text/plain; charset="US-ASCII" > > I do plan to formalize some external interfaces for the work that we have > done (and plan to do) in the next CDT release (2.0?). That being said, > IParserCallback is not yet near complete, as the parser still does not > parse statements and expressions fully. > > Referring to internal interfaces within the CDT core is not pretty, but > its not the end of the world either. :-) My concern in creating an > external interface too early is that we are still in the process of > scoping out the work required to be done for the next release; I would be > interested in discovering (soon!) the parser-related requirements that > your CDT-based products (Momentics, TimeStorm, etc.), as right now we are > focusing on getting the indexer/search enabled. > I was not thinking of the CDT-based products, the callback is necessary for the CDT to get things like indexer/search/StructureCreator etc .. working. An example, is how JDT is doing the indexer. The callback is ISourceElementRequestor { void acceptImport(..); void acceptMethod(..); ... } The indexer implements this and passes it to the JavaParser and when the elements are found adds them to the index table. The same for the JavaStructureCreator, the callback is to get the elements and the result is shown in a visual diff. My opinion is that we probably do not need to drill inside the blocks(well we'll have to reevaluate for Code Assist/Completion ...) at the moment, meaning we do not need the entire AST, no need for statements/expressions etc .. What the new parser is currently providing is enough. What it does not provide is a way to get the elements: ICSourceElementRequestor { void acceptInclude(...); void acceptFunction(...); } We used to have a IParserCallBack, but it is inadequate/incomplete to be of real use. > BTW, Sebastien, are we having a conference call tomorrow? > > JohnC > > > > > > "Douglas Schaefer" <dschaefe@xxxxxxxxxx> > 05/06/2003 11:31 AM > Please respond to cdt-dev > > To: cdt-dev@xxxxxxxxxxx > cc: > Subject: [cdt-dev] Re: CDT Parsing Callback > > > Moving to dev list. > > We basically put the interfaces in internal because we didn't feel they > were ready to make public. We should start moving them now as they start > to mature. I'll let John C handle the details. > > Cheers, > Doug Schaefer > Rational Software - IBM Software Group > Ottawa, Ontario, Canada > > > > > "Alain Magloire" <alain@xxxxxxx> > 05/06/2003 10:26 AM > > To: jcamelon@xxxxxxxxxxxx, hamer@xxxxxxxxxxxx > cc: Douglas Schaefer/Ottawa/IBM@IBMCA, dinglis@xxxxxxx > Subject: CDT Parsing Callback > > > > Bonjour > > The new parser does not provide a visible(1) callback > mechanism. > The old callback provided by the old parser was not extensible enough. > Any ideas on where to start. > > > (1) visible: meaning it is public an not under a org.eclipse.*.internal.* > The *internal* package name is reserve fo the implementation see eclipse > coding > conventions. > > > P.S.: I was not sure if you folks wanted to start this in the cdt-* > mailing list. > If you prefer, I can resend this email to the cdt-core-dev. > > > > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/cdt-dev > > > --=_alternative 0071003D85256D1E_= > Content-Type: text/html; charset="US-ASCII" > > > I do plan to formalize some external > interfaces for the work that we have done (and plan to do) in the next > CDT release (2.0?).  That being said, IParserCallback is not yet near > complete, as the parser still does not parse statements and expressions > fully. > > Referring to internal interfaces within > the CDT core is not pretty, but its not the end of the world either. :-) >  My concern in creating an external interface too early is that we > are still in the process of scoping out the work required to be done for > the next release; I would be interested in discovering (soon!) the parser-related > requirements that your CDT-based products (Momentics, TimeStorm, etc.), > as right now we are focusing on getting the indexer/search enabled. > > BTW, Sebastien, are we having a conference > call tomorrow? > > JohnC > > > > > <table width=100%> > <tr valign=top> > <td> > <td>"Douglas Schaefer" <dschaefe@xxxxxxxxxx> > 05/06/2003 11:31 AM > Please respond to cdt-dev > <td>        >         To: >        cdt-dev@xxxxxxxxxxx >         cc: >         >         Subject: >        [cdt-dev] Re: CDT Parsing Callback </table> > > > <tt>Moving to dev list. > > We basically put the interfaces in internal because we didn't feel they > > were ready to make public.  We should start moving them now as they > start > to mature.  I'll let John C handle the details. > > Cheers, > Doug Schaefer > Rational Software - IBM Software Group > Ottawa, Ontario, Canada > > > > > "Alain Magloire" <alain@xxxxxxx> > 05/06/2003 10:26 AM > >        To:     jcamelon@xxxxxxxxxxxx, hamer@xxxxxxxxxxxx >        cc:     Douglas Schaefer/Ottawa/IBM@IBMCA, > dinglis@xxxxxxx >        Subject:        CDT Parsing > Callback > > > > Bonjour > >                 The new parser > does not provide a visible(1) callback > mechanism. > The old callback provided by the old parser was not extensible enough. > Any ideas on where to start. > > > (1) visible: meaning it is public an not under a org.eclipse.*.internal.* > The *internal* package name is reserve fo the implementation see eclipse > > coding > conventions. > > > P.S.:  I was not sure if you folks wanted to start this in the cdt-* > > mailing list. > If you prefer, I can resend this email to the cdt-core-dev. > > > > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/cdt-dev > </tt> > > --=_alternative 0071003D85256D1E_=-- > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/cdt-dev > -- au revoir, alain ---- Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!! _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/cdt-dev

Follow-Ups:
- Re: [cdt-dev] Re: CDT Parsing Callback
  - From: Alain Magloire

References:
- Re: [cdt-dev] Re: CDT Parsing Callback
  - From: Alain Magloire

Prev by Date: [cdt-dev] Monthly conf. call rescheduled for next week
Next by Date: Re: [cdt-dev] Re: CDT Parsing Callback
Previous by thread: Re: [cdt-dev] Re: CDT Parsing Callback
Next by thread: Re: [cdt-dev] Re: CDT Parsing Callback
Index(es):
- Date
- Thread

Breadcrumbs