06 April 2009

Towards erlide 2.0: a service-oriented approach

"What, you're not even have a 1.0 out and are already talking about 2.0?", you ask. Well, yes! It's much more fun to think about the future!

One of my goals has always been to have as much as possible of the functionality on the Erlang side. This is simply because I prefer to code Erlang than Java. The reality of having to learn coding for Eclipse has made it difficult to pursue, one of the main reasons being that a lot of the boilerplate code is loaned from the Java Development Tools plug-in.

We have been slowly refactoring functionality to Erlang, but for 2.0 I see a different approach: implement a code handling engine in Erlang that really could use anything as a GUI. The API will probably be heavily influenced by the Eclipse way, but I can live with that.

So, what I have in mind is something like this:
  • the GUI sends notifications when there some editing event
  • the engine keeps a representation of the document in memory
  • the document is linked to a lexical scanner and a parser, for each change these will update their model of the source file
  • a higher-level model willl keep track of dependencies between files and their changes
Now, for the real work we will have extensible services, for example:
  • lexical info: tokens at a given position/range, ...
  • syntactic info: matching braces, ...
  • semantic info: language constructs at a given position (AST), ...
  • search: find definitions and uses of variables/functions/macros/records, ...
  • indentation
  • formatting
  • completion
  • annotations: warnings/errors from different tools (compiler, dialyzer,...)
  • refactoring
  • ...
The GUI will use these services and render them in an appropriate way, and of course will convert user input into the respective queries to these services.

Some of this functionality is already in place, but there's a lot of duplication and uncoordinated work. It's this that needs to get cleaned up.

2 comments:

Alain O'Dea said...

My erlang code completion module may be of use.

It uses erl_scan to build a token set from contextual text behind the cursor. It has no notion of "cursor" or "editor" it is just a humble completion algorithm. It reverses the token list and uses the nearby token type and order to determine what kinds of completions to provide and where to obtain them. It has also proven to be reasonably fast in the server configuration I wrote to work with TextMate. The roundtrip for a completions through erl_call stays under 100ms on my old 1.42GHz G4 PPC Mac mini.

It is certainly incomplete, but is easy to extend. I will gladly develop additional completions or answer any questions by email or phone about how to do so :)

I have licensed it under AFL v3.0 to allow absolute freedom of reuse or modification by anyone for any purpose with no constraints. I hope it is useful.

Vlad said...

Thanks a lot, Alain!

We're going to look at it to see how to fit it in our framework.

I wrote an issue for it at http://erlide.assembla.com/spaces/erlide/tickets/366