[news.eclipse.technology.ldt] Eclipse Dynamic [ was Re: Focus on DSLs: .

[Ed Warnicke <eaw@xxxxxxxxx>]

My sense is that the LDT is more focused on toolkits
needed to easily support languages.  It would be 
nice to see a home for new language projects in 
general.  This was the basic thought behind
the Eclipse Dynamic BOF at Eclipsecon.

What are the opinions?  Do we need a top level
Eclipse Dynamic project to host languages like 
Python, Perl, TCL, Ruby, PHP, etc or should
it be a subproject of the Eclipse Tools project,
or should it be a sub-sub-project of LDT?

Ed

Luis de la Rosa wrote:

> I agree with Chris Laffra and also suggest that we expand the charter to
> encompass other languages.
> 
> It should also be made easy to add new language support, like Chris Daly
> suggests, as a
> sub-sub-project.  Or perhaps we could have a new top-level Language
> Project that would be the
> umbrella for languages.  This would help signify that Eclipse is indeed a
> tool for many languages. Also having one home for all languages (something
> that came out of the Dynamic Languages BOF) would help users find what
> they need, as they currently have to go to many different places on the
> web to
> find all the languages.  I think Diego has a good survey of the current
> language plug-ins for
> Eclipse at http://diegop.blogspot.com/2005/02/eclipsed.html  A rough
> translation is available at
>
http://translate.google.com/translate?hl=en&sl=pt&u=http://diegop.blogspot.com/2005/02/eclipsed.html&prev=/search%3Fq%3Dhttp://diegop.blogspot.com/2005/02/eclipsed.html%26hl%3Den%26lr%3Dlang_en%26client%3Dsafari%26rls%3Den
> 
> 
> It would be nice if there could be some sort of process to help new
> languages get off the ground and
> then get graduating to higher and higher levels.  If there is enough
> effort behind each, they could get to where JDT is (but probably not since
> JDT is continually improving.)
> 
> 
> For example, the first stage would just be hosting the language in a
> "vanilla" editor and integrating the existing language tools as External
> Tools.
> 
> The second stage would add syntax highlighting (via say a keyword file.)
> 
> The third stage adds integrated running via the Launch/Console APIs.
> 
> The fourth stage adds debugging?
> 
> The fifth stage adds parsing and AST, which opens up things like an
> Outline View, refactoring, etc.
> 
> 
> This isn't exact, but it would be nice for implementors to see a clear
> path to how they can make
> their favorite language a first class citizen within Eclipse.  Also, it
> would be useful for users to know at what stage their language is
> supported.
> 
> Luis
> http://www.luisdelarosa.com/blog/
> 
> Chris Laffra wrote:
>> During EclipseCON we held a BOF on Language Toolkits (see my other
>> posting in this group).
>> In addition, a BOF was held on "Dynamic Languages".
>> Based on the outcome of both BOFs, some of us really would like to see
>> activities under the LDT structured in different focal sub-projects (not
>> in any particular order):
>> 
>> + Java-based languages sub-project
>> Find out how to reuse AST in similar Java-based languages (JSPs, etc.).
>> This sub-project would study the area as originally proposed by BEA
>> 
>> + Parser tools.
>> Collect eclipse plug-ins for Lex+Yacc, JavaCC, Antlr, JikesPG, Bison,
>> etc. etc. Standardize on AST interfaces so that parsers are exchangeable.
>> 
>> + Dynamic Languages.
>> Generic support for dynamically typed languages (LISP, PHP, Python,
>> Jython, Ruby, Groovy, etc). Study and support type inferencing
>> algorithms, code generation, interpreter design, etc.
>> 
>> + Editor frameworks.
>> Based on ASTs, provide tools/wizards to generate editors, hover help,
>> outline views, etc to quick-start small and modest IDEs.
>> 
>> + Makefile-based Languages.
>> Standardize on support for languages that have a 'make' style of building
>> programs (C, C++, Fortran, etc).
>> 
>> It will be hard to make the above classification orthogonal, and my
>> proposal here is just to start off a discussion.
>>