Ivan Lazar Miljenovic wrote::
My understanding of tab-completion in IDEs for Java, etc. is that it
just displayed every single possible class method for a particular
object value, and then did some kind of matching based upon what you
typed to narrow down the list, not that it was type-based.
Good completion is type based. For example, consider the following
situations in Eclipse:
(1) int foo = "bar".<cursor here>
(2) String foo = "bar".<cursor here>
In both cases, completion will only propose methods of String and its
super class Object, so the type of the receiver is taken into account.
Furthermore, the proposed methods will be ordered differently in (1) and
(2). In (1), the list of proposed methods starts with methods returning
int, while in (2), the list of proposed methods starts with methods
returning String, so the type of the context is taken into account.
I guess that it may be easier to implement effective completion for Java
because in Java, completion-relevant context information is often to the
left of the completion position.
On the other hand, shouldn't constraint-based type inference à la
Haskell be relatively easy to extend towards type-based completion? An
IDE could infer the types of the holes in half-finished source code, and
then try to unify the types of identifiers in scope with the type of the
hole the programmer is typing in. If the resulting constraint system is
consistent, the identifier should be proposed as a completion.
Tillmann
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
