Re: [Haskell-cafe] can Haskell do everyting as we want?
Marc Weber
Excerpts from Ivan Lazar Miljenovic's message of Wed Aug 04 12:37:29 +0200 2010:
functionality in Emacs.
I know - I patched the py backend for scion. I'm talking about:
node.getParent().getParent().<tab>Attributes["value"]
Or (let's talk about a haskell example):
pkgVersion $ package $ packageDescription
It feels unnatural to complete this. How should this be done? I know that you can define your own .dot. operator, so that you can write it in (let's call it Java style):
packageDescription .dot. package .dot. pkgVersion
I don't get the point of this ".dot." operator (which isn't even a valid operator).
Without completion I have to get the type of packageDescription, then follow the structure until I find Version. Using tags and Vim that's fast. Still completion is a lot faster.
Not really following your example here: you want something to write your code for you and read your mind to know what that code should be? 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.
I'm not talking about the universal "put everything in scope" completion thing - eg which Vim provides for some languages. I'm talking about really helpful context sensitive completion. I know its pretty hard to get this hard for Haskell - because type is determined by things you use. But the example I gave above is one which could be implemented easily.
How is it easy? How would this mythical completer know which function to use? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
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.
With Eclipse, try something like (within some method) String s = "foo"; s. (stop after the dot) and you see only methods of String (and Object). To me, that seems very much "type-based". Of course this requires the integration of parser and static analyzer with the editor - and you need to be able to parse and analyze partial programs. J.W.
Johannes Waldmann
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.
With Eclipse, try something like (within some method) String s = "foo"; s. (stop after the dot) and you see only methods of String (and Object). To me, that seems very much "type-based".
Well, yes, it is every single possible class method for a String object. However, if you tried to do "s.equalsIgnoreCase(", does it offer to insert every single String available and every function that could result in a String? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
However, if you tried to do "s.equalsIgnoreCase(", does it offer to insert every single String available and every function that could result in a String?
well, try this: String s = "foo"; String t = "bar"; int u = 42; s.equalsIgnoreCase( it suggests s, t, and null (but not u), so this is again type-based. if you try completion on s.equalsIgnoreCase(t. then you see that those methods that return a String, are at the front of the completion list. J.W.
On 4 August 2010 23:13, Johannes Waldmann
However, if you tried to do "s.equalsIgnoreCase(", does it offer to insert every single String available and every function that could result in a String?
well, try this:
String s = "foo"; String t = "bar"; int u = 42; s.equalsIgnoreCase(
it suggests s, t, and null (but not u), so this is again type-based.
Huh, last time I tried an IDE for Java (which was admittedly quite a while ago) it wouldn't do anything like that... I stand corrected then. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
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
Tillmann Rendel
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.
Yes, it knows which class methods are available. But can it list every possible argument that a given class method needs? IMHO, that is a closer analogy/comparison to what type-based completion for Haskell would require. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
participants (3)
-
Ivan Lazar Miljenovic -
Johannes Waldmann -
Tillmann Rendel