Completion thoughts

Well, now some massive changes have hit to Nemerle compiler, I think 
it's time to think again about the Completion Engine and how that 
relates to integration with IDEs other than MonoDevelop. The changes I 
would like to see are very big, but will sure allow us to get deeper 
integration (it would be greate to have Windows Forms development with 
Nemerle in #develop)

First of all, I don't like the way the Completion Engine has ended up 
(even though I've developed most of it). The best example is the 
RunCompletionEngine method. This method returns a list of every member 
that may be available into the context, and it translates them from the 
compiler representation to another representation. That seems fine, but 
when I integrated it into MD, I needed to wrap it again, making it a bit 
slow. My opinion is that we should stop returning every member and just 
return information about the context. For use in MD, that would be enough:

- Telling whether we are completing from a type (so members should be 
shown) or from a namespace (so classes should be shown)
- If completing from a type, return the *type of the expression*. I 
mean, if you tell the engine to complete

"def n = Hashtable ();
n.Add (5, "a");
n."

it should return the Hashtable.[int, string] as the type of n. 
Additionally, we could have another attribute whether the type is in the 
actual project of referenced in an external assembly.
- The members the object is allowed to call because of it context. For 
that, "AllowPrivate", "AllowInternal", "AllowProtected" would suffice.
- The extension classes that have member that would fit for the object.
With the latest three datas, an IDE will have enough information to show 
the completion window.

MD doesn't allow to colorize files dinamically (as far as I know), but 
for VSIP integration, I've read that a good interface to the lexer, 
including SaveState and RestoreState methods would be fine. Maybe, for 
just keyword colorizing from macros, we could access directly to the 
referenced assemblies and see the syntax from there, but we would loose 
colorization depending on the context.

Finally, the way the Type Tree is built needs to be reworked. As from 
now, the entire tree needed to be rebuilt from scratch every time 
something changed in some file, because the compiler was static. Now it 
has been turned more object-oriented (I think that was a very good 
decision from the compiler guys), we should allow to add / remove 
references on the fly, and also to update the state of the tree. So, in 
conclusion, I would rework the completion engine like that:

- Each engine should have its own state (which its mostly done, maybe 
remove the neccessity of Manager.Instance)
- Add / remove references on the fly
- Add / remove / replace code files, making the neccessary changes in 
the tree (that means, if I've updated one file with changes on some 
interface, alter the classes that implement it as needed). The only 
problem that I see are partial classes.
- I would remove the information about Defines, as IDEs usually don't 
use it to colorize
- Get the actual type tree in any moment, wrapping it in some way 
information is not retrieved until needed. That tree would be made of 
"Class" object with "Members" objects. Each member of the "Method" type 
would have an additional method: "PerformCompletion" that would take the 
string to complete and return the type of it as discussed above.

With that changes, I think we will have a better, easier to integrate 
and faster completion engine, usable from every IDE. I see it as a huge 
work, but I see we are lots of people interested on it.

Alejandro Serrano "Serras"

                
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com