[news.eclipse.technology.ldt] EclipseCON Language Toolkits BOF notes

["Chris Laffra" <Chris_Laffra@xxxxxxxxxx>]

During the EclipseCON BOF on language toolkits, I took notes. It was late in
the evening, and I may not have covered everyone's opinion, and I may have
misquoted certain people.
I had no time to clean up my notes. I hope they are meaningful.....

We had 60 (sixty!) people in the BOF, so apparently there is lot of interest
in this topic.

-- 
Chris Laffra, http://eclipsefaq.org




 ----------
Experience
----------

One person spoke up: Research Systems. Take JDT and fix it. Don't know where
to begin... Lots of work. Dynamically typed language is hard to support, JDT
is no framework.

Another person: We needed to support assembly languages. CDT was just
starting. Start from scratch. Basic tools. Everyone wants to be like JDT.
Following pydev and jython. Big learning curve. Lots of stuff could be
generic, but isn't. Use the source a lot. Lots of support related to Java.
Wade through the stuff. Direction is into multiple language area.

Person 3: We did refactoring participants in Ant editing. LTK dependency is
minimal. Where to put it if not in JDT?

For new languages, basically only Debug is reusable. Rest has to be built up
from the bottom up.

Contrast presentation vs. semantic analysis. Static typing vs. dynamic
languages. We need support for that, don't know quite what though?
Differences between CDT and JDT. Java has a particular view on what OO is.

Biggest challenge is parsing, to provide the context to give the completion
proposals. Do we need more support in addition to syntax highlight and the
triggering of content assist?

XDoclet add-ons to Java? Something like macros. Refactoring CPP is really
hard.

Language integration - shallow vs. deep. Everyone want to be like JDT.

Rename refactoring isn't a simple matter due to different scoping rules in
various languages.

JNI support in CDT would be cool. How about multi-language debugging.
Oooooohhhhhhh.
[half the room drooling by that thought...]

---------
Solutions
---------

Should be scope-oriented, not language-oriented. No silos. Need generic
editors, AST manipulation, Debugging, etc.

AST facade over different languages. Parse multiple languages into similar
AST structure. Common language and compiler infrastructure.

Need support across languages. Discover the Java classes in not only Java,
but also those in the plugin.xml and the JNI C code. Code generation is not
enough. Need to solve the interop problem.

Stop "Monkey see, monkey do". Don't replace J with one of the 25 other
letters in the alphabet.

Dependency tracking support.

Reusable/open search (in 3.0).

Multilanguage IDE is a nirvana?

Four problems (according to Dirk):

1. manage UI and real estate. Same menus, etc, at the same spot. Source
menu, refactoring menu. Copy the patterns from JDT UI. Should standardize
that. Not so hard to achieve. Push into a plugin. Doable for the JDT team.
Consisten UI story is a BIG step.

2. Mixed langauge support like JSP. Rename would visit two file. Extract
method from a Java source into a JST. Interaction between Java like
language. Like XML into Java. Assume there is a root language

3. Totally different language stack. Iinherit design principles, not
reinvent the wheel, and discard them purposely.

4. Mixing language - references between language assumes heterogenous model
between languages.


--------------
CONCLUSION
--------------


It is not the parser generation that is the problem. Adding a new language
to eclipse is hard. Multi-language support is even harder.

Support common UI plugin points. Try and find generic points for common
services.

We need a code generation fairy (as in "you can make three wishes...").

We need help from the JDT/CDT/AspectJ teams. We have new thinkers (like
BEA). Lots of opportunity to address the problem for disgruntled language
designers.