Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » DLTK and IBM Safari
| |
| Re: DLTK and IBM Safari [message #14871 is a reply to message #14842] |
Thu, 23 August 2007 22:41   |
Eclipse User |
|
|
|
Originally posted by: regenmacher.online.de
The eclipse technology project IMP will be based on Safari (=initial IBM
source code contribution) if accepted
Proposal: http://www.eclipse.org/proposals/imp/
michael
"Jae Gangemi" <jgangemi@gmail.com> schrieb im Newsbeitrag
news:fakvvu$ovh$1@build.eclipse.org...
> On 2007-08-23 00:03:20 -0400, Ali <saveez@hotmail.com> said:
>
>> Hi,
>>
>> How do you compare DLTK and IBM Safari? According to [1] safari has more
>> or less the same goals of DLTK. The more confusing thing is that Safari
>> is devloped by IBM, the company behinde eclipse which accepted a project
>> like DLTK, this sounds like some conflict to me.
>>
>>
>> [1]
>> http://domino.research.ibm.com/comm/research_projects.nsf/pa ges/safari.Introduction.html
>
>
>>
> from what i've read, they appear to be two different projects.
>
> the dltk is supposed to be a core framework for any dynamic scripting
> language, while safari looks like it is dealing w/ 3 specific languages
> (X10, XJ, JikesPG).
>
> maybe someone else will know something more.
>
> --
> -jae
>
|
|
|
| Re: DLTK and IBM Safari [message #14899 is a reply to message #14871] |
Fri, 24 August 2007 00:46 |
 Jae Gangemi
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
On 2007-08-23 18:41:25 -0400, "Michael Strothjohann"
<regenmacher@online.de> said:
> The eclipse technology project IMP will be based on Safari (=initial
> IBM source code contribution) if accepted
> Proposal: http://www.eclipse.org/proposals/imp/
thanks! that provides a much better explanation!
from the doc:
The DLTK is a related effort, but requires the use of a specific AST
class hierarchy to drive much of its functionality, which is not
suitable for arbitrary languages, nor for situations in which a
compiler front-end already exists. Nevertheless, we intend to
investigate what portions of the DLTK's infrastructure can be reused or
adapted.
--
i have noticed is that it is difficult to know all the pieces of the
pie are that need to go together, so it will be interesting to see
where things go, esp with this project.
i think once there is better documentation and some more code
refactoing in the language specific implementations (i try to do that
pull up work when i'm implementing something new in my perl plugin) -
it will definately be a lot easier to build implenentations for other
scripting languages.
and overall, there is definately a lot of code that could be pulled
outside of the dltk as well, such as code folding. there's a lot of
'behind the scenes' code cut and paste directly from the jdt - why
reinvent that wheel. should be very interesting to see how that
develops.
i do think one of the biggest hurdles will still be the source
parsing and creating the ModuleDeclaration containg all the ASTNode
objects.
--
-jae
|
|
|
| Re: DLTK and IBM Safari [message #14937 is a reply to message #14871] |
Sun, 26 August 2007 13:25 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Michael Strothjohann wrote:
> The eclipse technology project IMP will be based on Safari (=initial IBM
> source code contribution) if accepted
> Proposal: http://www.eclipse.org/proposals/imp/
>
> michael
>
Hum, reading that, it seems to me that there is a lot of overhead in the
two projects, even more they (IMP) might think. They state that "The
DLTK is a related effort, but requires the use of a specific AST class
hierarchy to drive much of its functionality, which is not suitable for
arbitrary languages, nor for situations in which a compiler front-end
already exists.", but in my experience (as mentioned in my other post)
that's not the case, there is still a lot to be gained even if one
doesn't use DLTK's AST hierarchy. Hum, maybe I should comment on this to
them.
--
Bruno Medeiros - MSc in CS/E student
|
|
|
| Re: DLTK and IBM Safari [message #15768 is a reply to message #14937] |
Mon, 27 August 2007 04:06 |
Andrey Platov
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Hi Bruno,
Thanks for commenting on this, we talked with SAFARI folks at EclipseCon
2007, so my current vision is following:
While SAFARI is focused on language, DLTK is primarily focused on
infrastructure (say JDT generalization and additional services).
I'd agree with you that IMP guys probably wrong saying that DLTK
strictly requires specific AST hierarchies. I think the truth is
opposite: DLTK allows end-user to use *any* parsing, etc approaches and
DLTK's AST-related classes shall not considered more than API layer
between language implementation details and whole infrastructure (for
DLTK components we're using 3 different approaches: hand-made parser for
Tcl, ANTLR based parser generating DLTK's AST for Python, and JRuby
parser for Ruby).
From one side this is not good since DLTK offers almost nothing for
concrete language IDE implementors in parse, code analysis, and similar
areas. However IMP project looks to have ideal fit in this areas, so if
IMP folks would decide to reuse DLTK's services I believe Eclipse will
have complete technologies stack for IDEs authoring.
Kind Regards,
Andrey
Bruno Medeiros wrote:
> Michael Strothjohann wrote:
>> The eclipse technology project IMP will be based on Safari (=initial
>> IBM source code contribution) if accepted
>> Proposal: http://www.eclipse.org/proposals/imp/
>>
>> michael
>>
>
> Hum, reading that, it seems to me that there is a lot of overhead in the
> two projects, even more they (IMP) might think. They state that "The
> DLTK is a related effort, but requires the use of a specific AST class
> hierarchy to drive much of its functionality, which is not suitable for
> arbitrary languages, nor for situations in which a compiler front-end
> already exists.", but in my experience (as mentioned in my other post)
> that's not the case, there is still a lot to be gained even if one
> doesn't use DLTK's AST hierarchy. Hum, maybe I should comment on this to
> them.
>
|
|
|
| Re: DLTK and IBM Safari [message #15784 is a reply to message #15768] |
Mon, 27 August 2007 04:43 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Andrey,
Please see my posts in technology.imp. I have suggested that dltk and
imp could be merged together as they have the potential to make a new
project that readily ticks many boxes that they do not do at the time.
This would be a win for dltk, a win for imp and certainly a win for the
community.
Andrey Platov wrote:
> Hi Bruno,
>
> Thanks for commenting on this, we talked with SAFARI folks at EclipseCon
> 2007, so my current vision is following:
>
> While SAFARI is focused on language, DLTK is primarily focused on
> infrastructure (say JDT generalization and additional services).
>
> I'd agree with you that IMP guys probably wrong saying that DLTK
> strictly requires specific AST hierarchies. I think the truth is
> opposite: DLTK allows end-user to use *any* parsing, etc approaches and
> DLTK's AST-related classes shall not considered more than API layer
> between language implementation details and whole infrastructure (for
> DLTK components we're using 3 different approaches: hand-made parser for
> Tcl, ANTLR based parser generating DLTK's AST for Python, and JRuby
> parser for Ruby).
>
> From one side this is not good since DLTK offers almost nothing for
> concrete language IDE implementors in parse, code analysis, and similar
> areas. However IMP project looks to have ideal fit in this areas, so if
> IMP folks would decide to reuse DLTK's services I believe Eclipse will
> have complete technologies stack for IDEs authoring.
>
> Kind Regards,
> Andrey
>
> Bruno Medeiros wrote:
>> Michael Strothjohann wrote:
>>> The eclipse technology project IMP will be based on Safari (=initial
>>> IBM source code contribution) if accepted
>>> Proposal: http://www.eclipse.org/proposals/imp/
>>>
>>> michael
>>>
>>
>> Hum, reading that, it seems to me that there is a lot of overhead in
>> the two projects, even more they (IMP) might think. They state that
>> "The DLTK is a related effort, but requires the use of a specific AST
>> class hierarchy to drive much of its functionality, which is not
>> suitable for arbitrary languages, nor for situations in which a
>> compiler front-end already exists.", but in my experience (as
>> mentioned in my other post) that's not the case, there is still a lot
>> to be gained even if one doesn't use DLTK's AST hierarchy. Hum, maybe
>> I should comment on this to them.
>>
|
|
|
| Re: DLTK and IBM Safari [message #15827 is a reply to message #15784] |
Mon, 27 August 2007 05:33 |
Andrey Platov
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Hello Ali,
Great suggestion, thank you! So let's see what road IMP folks would
take. From DLTK side I believe it would be possible to rely on some of
IMP project components to make IDE implementor life much more better.
Kind Regards,
Andrey
Ali wrote:
> Andrey,
>
> Please see my posts in technology.imp. I have suggested that dltk and
> imp could be merged together as they have the potential to make a new
> project that readily ticks many boxes that they do not do at the time.
> This would be a win for dltk, a win for imp and certainly a win for the
> community.
>
> Andrey Platov wrote:
>> Hi Bruno,
>>
>> Thanks for commenting on this, we talked with SAFARI folks at
>> EclipseCon 2007, so my current vision is following:
>>
>> While SAFARI is focused on language, DLTK is primarily focused on
>> infrastructure (say JDT generalization and additional services).
>>
>> I'd agree with you that IMP guys probably wrong saying that DLTK
>> strictly requires specific AST hierarchies. I think the truth is
>> opposite: DLTK allows end-user to use *any* parsing, etc approaches
>> and DLTK's AST-related classes shall not considered more than API
>> layer between language implementation details and whole infrastructure
>> (for DLTK components we're using 3 different approaches: hand-made
>> parser for Tcl, ANTLR based parser generating DLTK's AST for Python,
>> and JRuby parser for Ruby).
>>
>> From one side this is not good since DLTK offers almost nothing for
>> concrete language IDE implementors in parse, code analysis, and
>> similar areas. However IMP project looks to have ideal fit in this
>> areas, so if IMP folks would decide to reuse DLTK's services I believe
>> Eclipse will have complete technologies stack for IDEs authoring.
>>
>> Kind Regards,
>> Andrey
>>
>> Bruno Medeiros wrote:
>>> Michael Strothjohann wrote:
>>>> The eclipse technology project IMP will be based on Safari (=initial
>>>> IBM source code contribution) if accepted
>>>> Proposal: http://www.eclipse.org/proposals/imp/
>>>>
>>>> michael
>>>>
>>>
>>> Hum, reading that, it seems to me that there is a lot of overhead in
>>> the two projects, even more they (IMP) might think. They state that
>>> "The DLTK is a related effort, but requires the use of a specific AST
>>> class hierarchy to drive much of its functionality, which is not
>>> suitable for arbitrary languages, nor for situations in which a
>>> compiler front-end already exists.", but in my experience (as
>>> mentioned in my other post) that's not the case, there is still a lot
>>> to be gained even if one doesn't use DLTK's AST hierarchy. Hum, maybe
>>> I should comment on this to them.
>>>
|
|
|
| Re: DLTK and IBM Safari [message #15976 is a reply to message #14842] |
Wed, 29 August 2007 13:43 |
Robert M. Fuhrer
Messages: 294
Registered: July 2009 |
Senior Member |
|
|
Jae Gangemi wrote:
> On 2007-08-23 00:03:20 -0400, Ali <saveez@hotmail.com> said:
>
>> Hi,
>>
>> How do you compare DLTK and IBM Safari? According to [1] safari has
>> more or less the same goals of DLTK. The more confusing thing is that
>> Safari is devloped by IBM, the company behinde eclipse which accepted
>> a project like DLTK, this sounds like some conflict to me.
>>
>>
>> [1]
>> http://domino.research.ibm.com/comm/research_projects.nsf/pa ges/safari.Introduction.html
>>
>
>
>>
> from what i've read, they appear to be two different projects.
>
> the dltk is supposed to be a core framework for any dynamic scripting
> language, while safari looks like it is dealing w/ 3 specific languages
> (X10, XJ, JikesPG).
Hi,
I'm the project lead for the Eclipse IMP (formerly known as SAFARI).
IMP is a very general framework, and isn't simply interested in X10, XJ
and JikesPG/LPG. X10 and LPG are merely example IDEs built using IMP,
and are offered as indications of the different kinds of languages that
IMP can support. [X10 is an OO language designed for highly concurrent
programs; LPG is a parser/lexer generator, a very different kind of
language.]
So you can see that IMP is not solely concerned with dynamic languages.
In fact, although a team in Tokyo has built a simple JavaScript IDE using
IMP, we really haven't spent much energy on dynamic languages so far. IMP
is trying hard to avoid biases toward any particular family of languages.
Ultimately, we want to provide the tools to support mainstream programming
languages (including dynamic languages), less commonly used languages, as
well as domain-specific languages of all sorts.
Our approach is based on meta-tooling and meta-programming, which as far
as I know, is not part of the DLTK mission. We're interested in exploring
exactly how best to help people specify language-specific bits of IDE
appearance and behavior, all the way from simple syntax highlighting to
(in the long run) static analysis, program understanding, and refactoring.
So although IMP does of necessity provide a runtime API for language-specific
IDEs to build upon, that's not our only focus.
In fact, based on my previous work on refactoring for the Eclipse JDT,
we have a strong interest in providing a reusable static analysis and
refactoring framework that will support the implementation of more
challenging refactorings such as "Extract Method", "Infer Type Arguments".
Historically, IMP started out as a small project with IBM Research
before the DLTK became an Eclipse project, and they proceeded independently.
We only became aware of the DLTK late last year, and took the opportunity
to talk to the DLTK team at EclipseCon '07 to start to figure out how we
think the projects relate.
We're not trying to compete with the DLTK. They're doing a terrific job
supporting a very important class of programming languages. Yes, there
appears to be some overlap between our goals, and because of that, we
look forward to working with them to figure out how the two projects
should relate. All the same, we do have a different, and more general,
mission, so we believe there is room in the Eclipse community for both
projects.
Part of the point of the community review period is for you all to help
determine what should be the scope of the IMP project. Perhaps parts of
IMP will be folded into the DLTK. Perhaps parts of the DLTK might be
promoted to the LTK (which itself has no active project at this time),
or to the IMP, after some generalization. There are many possibilities.
Hope this helps clear up some of the confusion! If not, just ask more
questions, and let's get the dialog moving!
> maybe someone else will know something more.
>
|
|
|
| Re: DLTK and IBM Safari [message #15994 is a reply to message #15768] |
Wed, 29 August 2007 14:56 |
Robert M. Fuhrer
Messages: 294
Registered: July 2009 |
Senior Member |
|
|
Andrey Platov wrote:
> Hi Bruno,
>
> Thanks for commenting on this, we talked with SAFARI folks at EclipseCon
> 2007, so my current vision is following:
>
> While SAFARI is focused on language, DLTK is primarily focused on
> infrastructure (say JDT generalization and additional services).
>
> I'd agree with you that IMP guys probably wrong saying that DLTK
> strictly requires specific AST hierarchies. I think the truth is
> opposite: DLTK allows end-user to use *any* parsing, etc approaches and
> DLTK's AST-related classes shall not considered more than API layer
> between language implementation details and whole infrastructure (for
> DLTK components we're using 3 different approaches: hand-made parser for
> Tcl, ANTLR based parser generating DLTK's AST for Python, and JRuby
> parser for Ruby).
Hi Andrey,
The (possibly broken) understanding I came away with from our conversation
at EclipseCon was that the various DLTK views (editor, outline, etc.) talk
to the DLTK AST classes directly. So any supported language must either be
represented directly as DLTK ASTs, or provide wrappers to adapt the "native"
(language-specific) ASTs to what the DLTK expects. Is that wrong?
If that's correct, then I think that may be a fine way to approach dynamic
languages (which is great, since that's what the "D" in "DLTK" stands for),
but it may not work so well for very different languages (say grammar
specification languages, LaTeX, makefiles, or arbitrary DSLs) that have
fundamentally different structure and semantics.
[To be clear, we're not saying that the DLTK requires a particular parsing
technology (a good thing, and something the IMP also doesn't require).
Perhaps we should try to make that more clear in our project proposal. I'm
also not saying we know yet how to support such a vast range of languages.
But then the purpose of the IMP project, being a technology project, is to
serve as a place to work out the ideas and the implementation.]
On the infrastructure front, the IMP's runtime layer may have a fair amount
in common with the analogous layer in the DLTK. That might be a great
opportunity for us to share code and ideas (and perhaps promote some of that
to the LTK). We still need to start going through the DLTK code base to see
what's there that we can use or generalize, as well as what we can offer to
help improve things.
It may turn out that one big difference between the IMP and the DLTK is how
the IDE developer obtains the language-specific code that talks to the runtime
layer. The IMP takes a meta-tooling approach, using code generation and
declarative DSLs to keep the developer's focus on the language-specific bits,
and abstracting away the boilerplate and Eclipse APIs. If this is the main
difference, then that's great; the two toolkits would be complementary. In
that scenario, the IMP could become a sort of "meta-tooling front end" for the
DLTK. (That obviously assumes that the DLTK runtime components are usable for
the wide range of languages we want to support.)
> From one side this is not good since DLTK offers almost nothing for
> concrete language IDE implementors in parse, code analysis, and similar
> areas. However IMP project looks to have ideal fit in this areas, so if
> IMP folks would decide to reuse DLTK's services I believe Eclipse will
> have complete technologies stack for IDEs authoring.
As you say, we have a strong interest in reusable static analysis, especially
in support of refactoring and program understanding. We also have a strong
interest in parsing technology (along with AST generation and various other
front-end analyses), but some of that borders dangerously on religion, so
although we've spent time developing our own parser generator, IMP itself
stands on neutral ground. :-) I.e., people feel strongly about their choice
of parsing technology, so IMP's goal is to be accommodating rather than try
to sway people to our parsing technology.
Again, we're not trying to compete with the DLTK; the overlap arose simply
because the two projects started out life independently and only became
aware of each other relatively recently. One major purpose of the project
proposal's public review is precisely to determine the proper scope of the
efforts, and in particular, to determine the relationship between the IMP
and the DLTK.
Anyway, hope this helps clear things up a bit.
>
> Kind Regards,
> Andrey
>
> Bruno Medeiros wrote:
>> Michael Strothjohann wrote:
>>> The eclipse technology project IMP will be based on Safari (=initial
>>> IBM source code contribution) if accepted
>>> Proposal: http://www.eclipse.org/proposals/imp/
>>>
>>> michael
>>>
>>
>> Hum, reading that, it seems to me that there is a lot of overhead in
>> the two projects, even more they (IMP) might think. They state that
>> "The DLTK is a related effort, but requires the use of a specific AST
>> class hierarchy to drive much of its functionality, which is not
>> suitable for arbitrary languages, nor for situations in which a
>> compiler front-end already exists.", but in my experience (as
>> mentioned in my other post) that's not the case, there is still a lot
>> to be gained even if one doesn't use DLTK's AST hierarchy. Hum, maybe
>> I should comment on this to them.
>>
|
|
| |
| Re: DLTK and IBM Safari [message #16048 is a reply to message #15994] |
Fri, 31 August 2007 19:26 |
| Eclipse User |
|
|
|
Originally posted by: brunodomedeiros+spam.com.gmail
Robert M. Fuhrer wrote:
> Andrey Platov wrote:
>> Hi Bruno,
>>
>> Thanks for commenting on this, we talked with SAFARI folks at
>> EclipseCon 2007, so my current vision is following:
>>
>> While SAFARI is focused on language, DLTK is primarily focused on
>> infrastructure (say JDT generalization and additional services).
>>
>> I'd agree with you that IMP guys probably wrong saying that DLTK
>> strictly requires specific AST hierarchies. I think the truth is
>> opposite: DLTK allows end-user to use *any* parsing, etc approaches
>> and DLTK's AST-related classes shall not considered more than API
>> layer between language implementation details and whole infrastructure
>> (for DLTK components we're using 3 different approaches: hand-made
>> parser for Tcl, ANTLR based parser generating DLTK's AST for Python,
>> and JRuby parser for Ruby).
>
> Hi Andrey,
>
> The (possibly broken) understanding I came away with from our conversation
> at EclipseCon was that the various DLTK views (editor, outline, etc.) talk
> to the DLTK AST classes directly. So any supported language must either be
> represented directly as DLTK ASTs, or provide wrappers to adapt the
> "native"
> (language-specific) ASTs to what the DLTK expects. Is that wrong?
Not exactly. (I'm not a DTLK expert, but I'll venture my answer, based
on my experience so far) Many features in DLTK, such as outline,
indexing and a few editor features, are directly based on model elements
(the structure analogous to JDT's IJavaElement's). These model elements
are created from the AST, but you have complete control on how to
create such elements (given your ISourceElementParser), and don't have
to use the DLTK AST hierarchy at all for this (not even ASTNode).
Other features however, such as searching, code folding, code hovers,
find definition, code completion, etc., have default implementations
that depend on varying degrees on the DTLK AST hierarchy. Still, you can
always provide an implementation of your own that works with your AST
hierarchy. The extra work involved and degree of integration obtained
varies with the particular feature. I adapted find-definition and
editor folding into DLTK very easily. Search feature (search
declarations, references, etc.) is underway and will require some work
since it relies a lot on DLTK AST hierarchy. Code completion was already
implemented without using any DLTK infrastructure, so I didn't adapt it
to DLTK (not sure if there is anything to gain).
> On the infrastructure front, the IMP's runtime layer may have a fair amount
> in common with the analogous layer in the DLTK. That might be a great
> opportunity for us to share code and ideas (and perhaps promote some of
> that
> to the LTK). We still need to start going through the DLTK code base to see
> what's there that we can use or generalize, as well as what we can offer to
> help improve things.
>
Yes, that seems to be case.
> It may turn out that one big difference between the IMP and the DLTK is how
> the IDE developer obtains the language-specific code that talks to the
> runtime
> layer. The IMP takes a meta-tooling approach, using code generation and
> declarative DSLs to keep the developer's focus on the language-specific
> bits,
> and abstracting away the boilerplate and Eclipse APIs. If this is the main
> difference, then that's great; the two toolkits would be complementary. In
> that scenario, the IMP could become a sort of "meta-tooling front end"
> for the
> DLTK. (That obviously assumes that the DLTK runtime components are
> usable for
> the wide range of languages we want to support.)
>
That seems a very nice idea, and meta-tooling seems a fine way to be
able to quickly produce a working IDE without having to learn much of
Eclipse (which is *huge*). However I think the doors to using Eclipse
and infrastructure APIs should always remain open, and not undermined
because of the existence of meta-tooling. The reason is that in somee
situations people will eventually want to do more advanced things, and
meta-tooling, by its very nature, may not allow doing some of those
advanced & specific things. (I've heard of this happening in other
contexts, like game programming, which could be analogous to the
situation here).
--
Bruno Medeiros - MSc in CS/E student
|
|
|
Goto Forum:
Current Time: Sat Jul 27 05:29:31 GMT 2024
Powered by FUDForum. Page generated in 0.04784 seconds |
] 
Search
Help
Register
Login
Home
