Re: [imp-dev] Integrating with existing Eclipse-based IDEs - what can IM

[Jin Mingjian <jin.phd@xxxxxxxxx>]

hi, Clemens. I guess that, you want to pick DLTK JS IDE to use, add
some more high-level functionalities to it(formatting?refactoring?).
right? I have not the much experiences with JS and DLTK's JS IDE. I am
not very clear about the current status of IMP. some initial supports
should be there. I have not tested much such functionalities:) From a
general viewpoint, I think, some high-level refactorings are not
trivial. However, for your code completion case, I guess it is not
very hard if you have the AST from the context.(AST under errors is
another topic, it is related to the capability of your parser)
As my testing, the lpg-based thing like parser is not very important
if you have a existed parser. some example is implemented in lpg, but
you will find all you need is to implement 2 or some Interfaces.



2009/4/15 Clemens Anhuth <clemens@xxxxxxxxxxxxx>:
> Stan Sutton wrote:
>
> [...]
>>
>> I don't have a very clear picture of what you're trying to do.  As Jin
>> suggests, IMP, DLTK, and EPIC are different kinds of tools or platforms and
>> have different positions with regard to language support (representation,
>> tooling, runtime/debug).
>>
>> Can you say more about what your third API is and what the integration is
>> supposed to achieve?
>
> Hello Jin, Stan,
>
> sorry, that should have been "third party API".
>
> My company provides a software that comes with support for running scripts
> in Perl, Python, Tcl and JavaScript. The current IDE for writing these
> scripts will be replaced with an Eclipse-based IDE. The first choices for
> this so far are DLTK and EPIC. (The plugins that make up the new IDE will be
> usable separately, so that one can install the new IDE's functionality into
> an existing installation of EPIC or DLTK.)
>
> The software exposes the same API to any of the script language
> interpreters. The API does not exist in form of script files. (As such the
> situation is similar to that of writing JavaScript scripts for Adobe or
> Microsoft products, each having their own APIs and extensions
> exposed/embedded to/in their interpreters, ready to be used in scripts
> without further configuration.)
>
> Writing the scripts can be done with any text editor or IDE, but then code
> completion support for that particular API is missing.
>
> We want to offer that code completion support for our API in DLTK and EPIC,
> but also in any other Eclipse-based IDE, if possible. (Where possible we
> want to integrate our own code completion seamlessly, like can be done with
> the respective extension point in DLTK. Where seamless integration is not
> possible we would like to offer our own code completion functionality to be
> triggered with a key combination.)
>
> To me it seemed that this is maybe where org.eclipse.imp.analysis has
> something to offer.
>
>
>
>>
>> I haven't worked on org.eclipse.imp.analysis or made use of it.  It should
>> help you in implementing AST-based analyses.  I can't comment on its
>> readiness for use, though.
>
> OK.
>
>>
>> More broadly, IMP is not an IDE but is metatooling mainly to facilitate
>> the development of IDE services or features.  Many of these are oriented
>> around the editor but some are not.  The IDE developer must provide basic
>> parsing services and an AST representation.  The IMP runtime for editing and
>> other services generally rely on these.  Strictly speaking, the language
>> tooling and AST representation are not part of or provided by IMP, although
>> IMP does come "bundled" with the LPG parser generator which can be used to
>> generate a parser and AST representation.  Other approaches to parsing/AST
>> support can also be accommodated.
>
> I see. So if for example I found that the AST support for DLTK's JavaScript
> IDE implementation lacking I could use LPG to create a parser to get an AST
> which I can use with org.eclipse.imp.analysis to make use of the features
> provided by that?
>
>
>
>> Given an implementation of the parsing services and AST representation,
>> IMP provides leverage for development of IDE services.  The image below
>> gives an indication of services currently addressed (this is the IMP
>> contribution to the Eclipse "New" menu).  It's not clear if any of these
>> would be helpful for your purposes.  However, even if they don't address
>> your main focus you may still find some of them nice to have.
>
> Reference resolver, Content proposer, Documentation provider, Hover helper
> all sound like they could be related to code completion or to providing
> helpful information while writing code, more or less directly, but that's
> only from guessing by their name.
>
>
>
> I guess the main problem I am still looking a good solution for is type
> detection (is that called type inference?) to be able to provide code
> completion of members of "obj" in cases like this one:
>
>  var objName = "name of an object";
>  var obj = findObject(objName);
>
> What seems tricky to me about this is that the "type" returned by
> findObject() (which is not implemented as/in a script file) is determined by
> the actual name passed to it.
>
> This example has one indirection to passing the name to findObject() (via
> the variable objName) and I think I can imagine how to analyse the AST to
> get the actual name passed. But I guess I wonder if that is still possible
> when there are more indirections, and whether IMP or
> org.eclipse.imp.analysis already has some feature to do or help doing this.
>
>
>
> With best regards
>
> Clemens Anhuth
>
> _______________________________________________
> imp-dev mailing list
> imp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/imp-dev
>