Re: [cdt-dev] adding a new language to the CDT

[Chris Recoskie <recoskie@xxxxxxxxxx>]

The concerns of supporting different languages cannot always easily be separated. We live in a world where users freely link together object files compiled from all manner of different languages. A user might have a Fortran program that calls C or C++ code, for instance.

Ideally, tools should be able to handle this scenario. For example, if I do a call hierarchy on a C function that's called from a Fortran function, I would expect to see that Fortran function listed and be able to navigate to it.

Since the CDT already has an infrastructure and implementation for such things as preprocessing, parsing, indexing, and analysis of program constructs, it becomes desirible to try to hook into that, both from the point of view of cross language tools, and from the point of view of reusing existing infrastructure. Why invent another C/C++ wheel when you can use the one that's already there? Granted, this is not always easy, and has its own problems, but it's a place to start.

The aforementioned IMP project people have been working on the idea of generic ASTs where some common concepts like parameterized functions and things like that can be reused across many language. An interesting idea, but I'm not sure how far they've gotten with that or ultimately how successful it will be.

The idea of factoring out common language support APIs and services into a common place is interesting, but I don't think we're at the point where it's realistic to try to attempt that as a "step function", given the level of resources we have. It makes more sense to me to incrementally improve and genericize what we have for now, and someday, when the time comes where we think we have something viable for generic consumption, then we think about refactoring that code into some common package.

===========================

Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt

"Tom Ball" <tball@xxxxxxxxxx>

"Tom Ball" <tball@xxxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

10/28/2008 01:42 PM

Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

To	"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
cc
Subject	Re: [cdt-dev] adding a new language to the CDT

Good luck implementing that vision, as it's a potential bog to avoid.
IDEs need to model the languages they support, and the more deeply you
integrate specific language support into the IDE, the more unique your
language model needs to be. Why doesn't CDT use JDT?  It has a lot to
do with how different an accurate Java model is from a good C++ model.
 Anyone intrigued by the notion that a common model can be created to
support all languages should review how poorly MOF
(http://www.omg.org/mof/) is used outside of a few UML tools.  The
tone of this response is a bit vehement because I had the misfortune
to work on a MOF-related project, which eventually had to be put to
sleep in spite of the hard work of many very smart engineers.

It's very likely that CDT has valuable language-independent
technology, but the best approach (IMHO) is to extract that code to a
separate package which can be shared by other languages without mixing
language issues   Eclipse has already started that work with LTK, and
my personal view is that time invested in that and similar efforts
will have a bigger payoff and lower risk of getting stuck, especially
as the number of supported languages increases.

NetBeans recently worked around this by providing a lightweight common
language framework (http://wiki.netbeans.org/Schliemann), which
language implementors can invest different amounts of effort to get
different levels of integration.  I'm not saying that Eclipse should
do things the NetBeans-way (I want to see my next birthday! :-), but
it demonstrates the case for having a common language integration
framework which languages independently extend, rather than one
language extending another's.

Tom

On Tue, Oct 28, 2008 at 10:15 AM, Hilliard, Bill
<bill.hilliard@xxxxxxxxx> wrote:
> Actually, there is a goal of making CDT extendible to support multiple
> languages.  See the "Vision Statement" slides on the wiki from the Fall
> 2005 CDT summit.  Also, see the Eclipse technology Photran project which
> builds a Fortran IDE over CDT.  In Addition, Doug S. has commented in
> the past about his efforts to build an Ada support package over CDT.
> Jeff Overbey of the Photran project wrote a white paper about adapting
> CDT to other languages.  You might see if that has helpful information
> for you.
>
> Bill
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Tom Ball
> Sent: Tuesday, October 28, 2008 12:45 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] adding a new language to the CDT
>
> I'm not a CDT expert, but what you describe seems like a backwards
> approach:  JDT and CDT are purposely specific to their respective
> languages, so new languages should have their own specific IDE support
> rather than warp another language's.  There are several Eclipse
> plug-in API packages to make this easier, such as LTK which provides
> common refactoring support.  My suggestion is to write separate IDE
> support for your language, but use CDT and JDT as best-of-class
> example code.
>
> Tom
>
> On Tue, Oct 28, 2008 at 6:14 AM, Michael Rosenfelder
> <MROSENFE@xxxxxxxxxx> wrote:
>>
>> Hi,
>> I'm working on an Eclipse Plug-In to support a procedural programming
>> language called PL8, a PL/I variant for systems programming. We have
> PL8 and
>> C source files in one source tree (project). Our compiler builds all
> files
>> to object files and then they are linked together to one binary. It is
>> possible to call a C-function from a PL8-function and vice versa. So
> our
>> idea was to use the CDT and treat the source tree as a C/C++ project.
> The
>> C/C++ files will be handled by CDT and the PL8 files are handled by a
> PL8
>> editor (Syntax highlighting, outline view). We also want to use the
> code
>> navigation feature in the PL8 context. Therefore our idea was to add
> some
>> informations like function definitions in the C-index. We created a
> Java
>> class PL8Language implementing the ILanguage interface from the
> ILanguage
>> Extension Point of the CDT. The parser of the PL8 should not create an
> own
>> index, but should add the functions of PL8 language to the index,
> created by
>> the CDT-Parser.
>> If I click e.g. on a PL8-function in a C-file, the C-indexer searches
> for
>> the function in the now combined index for the location of the
> function and
>> jumps to it. If I click in a PL8-file, my own indexer searchs for the
>> function in the combined index.
>>
>> I think the solution is to implement the getASTTranslationUnit and my
> own
>> ModelBuilder.
>> I tried to implement the getASTTranslationUnit in this way.
>>
>> public IASTTranslationUnit getASTTranslationUnit(CodeReader reader,
>>                         IScannerInfo scanInfo, ICodeReaderFactory
>> fileCreator,
>>                         IIndex index, IParserLogService log) throws
>> CoreException {
>>
> System.out.println("PL8Language::getASTTranslationUnit");
>>                 final ISourceCodeParser parser= new
>> PL8SourceCodeParser(index);
>>                 // Parse
>>                 IASTTranslationUnit ast= parser.parse();
>>                 return ast;
>>
>>         }
>>
>> The parse function of my SourceCodeParser looks like the following:
>>
>> public IASTTranslationUnit parse() {
>>                 System.out.println("PL8SourceCodeParser::parse");
>>                 IASTTranslationUnit result;
>>                 //Create a new TranslationUnit
>>                 translationUnit = new CASTTranslationUnit();
>>                 translationUnit.setOffset(0);
>>                 translationUnit.setIndex(index);
>>
>>                 //Name of the function
>>                 char name_str[] = {'A', 'B'};
>>                 CASTName declaratorName = new CASTName(name_str);
>>
>>                 //new SimpleDeclaration
>>                 IASTSimpleDeclaration declaration = new
>> CASTSimpleDeclaration();
>>
>>                 IASTStandardFunctionDeclarator declarator = new
>> CASTFunctionDeclarator(declaratorName);
>>                 declaration.addDeclarator(declarator);
>>
>>                 CASTSimpleDeclSpecifier declSpec = new
>> CASTSimpleDeclSpecifier();
>>                 declaration.setDeclSpecifier(declSpec);
>>
>>                 translationUnit.addDeclaration(declaration);
>>
>>                 result = translationUnit;
>>                 translationUnit = null;
>>
>>                 return result;
>>         }
>>
>> The goal is to add a function AB to the index. But the current
> situation is
>> different. There is no function with the name AB in the index and at
> the
>> moment I had no idea what the reason is. The return value of the parse
>> function is the right one. The return value has the function included.
>> At the moment I found no other way to write into the index, which is
> used
>> for the source code navigation.
>>
>> I also searched for a solution in the CDT Wiki in the topic Design. It
> is
>> clearly explained about the CDT works, but no explanation how I can
>> implement my idea.
>>
>> So my question to you, where is my mistake or is it generally possible
> to
>> implement my idea?
>> Is there anything additional I have to do or can you point me to an
> example
>> ?
>>
>> Thank you in advance!
>>
>> Kind regards
>>
>> Michael
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev