[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [photran-dev] Development directions and thoughts from Supercomputing
|
The main use cases for this is mixed language projects, where you have
Fortran code calling C/C++ code, and/or vice versa. This means that you
want navigation, content assist, call hierarchy, search, etc. to work
across language boundaries.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
Jeffrey Overbey
<subscribe-photra
n-dev@xxxxxxxxx.b To
z> Photran Developer Info
Sent by: <photran-dev@xxxxxxxxxxx>
photran-dev-bounc cc
es@xxxxxxxxxxx
Subject
Re: [photran-dev] Development
16/11/2007 06:46 directions and thoughts from
PM Supercomputing
Please respond to
overbey2@xxxxxxxx
; Please respond
to
Photran Developer
Information
<photran-dev@ecli
pse.org>
> There are a lot of interesting things we can do if we bring the two
AST/DOM
> things together. With the help of Beth and other Eclipsers that cross the
Definitely. I should elaborate on this a little.
A large part of my dissertation will focus on program representations
that make refactoring tools easy to build. My goal is to do a tutorial
at EclipseCon 2010 where the participants build an entire
(well-designed) refactoring engine and two or three refactorings during
the tutorial. Without going into detail, though, let's just say that
requires some flexibility in the AST nodes and a somewhat strange
program database. And I want to use Photran as a large-scale test-case.
On the other hand, though, there's a lot of incentive on the IDE side to
integrate with CDT. PDOM will get us search, and for some other things
(e.g., PLDT) there is an incentive to reuse some aspects of the CDT DOM
as well.
It is stupid to build two different ASTs for one IDE, but neither
approach will serve all of our goals. So what I would like to do is
basically build CDT interfaces onto our other representation "on
demand." Beth's generic PldtAstVisitor is using these:
import org.eclipse.cdt.core.dom.ast.IASTDeclaration;
import org.eclipse.cdt.core.dom.ast.IASTExpression;
import org.eclipse.cdt.core.dom.ast.IASTFileLocation;
import org.eclipse.cdt.core.dom.ast.IASTIdExpression;
import org.eclipse.cdt.core.dom.ast.IASTLiteralExpression;
import org.eclipse.cdt.core.dom.ast.IASTMacroExpansion;
import org.eclipse.cdt.core.dom.ast.IASTName;
import org.eclipse.cdt.core.dom.ast.IASTNode;
import org.eclipse.cdt.core.dom.ast.IASTNodeLocation;
import org.eclipse.cdt.core.dom.ast.IASTPreprocessorMacroDefinition;
import org.eclipse.cdt.core.dom.ast.IASTStatement;
import org.eclipse.cdt.core.dom.ast.IASTTranslationUnit;
import org.eclipse.cdt.core.dom.ast.IBinding;
I hope building these interfaces in will only take a few hours, so I can
cover that. If there's a demand for other CDT nodes/interfaces, we can
discuss that later.
Which brings me to a question... hypothetically, if we had a 100% CDT
DOM-compliant AST, what could we do? (The next question, of course, is,
How many DOM interfaces would we need to implement on our existing AST
to achieve the same?)
Jeff
_______________________________________________
photran-dev mailing list
photran-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/photran-dev
