Does LightTable have autocompletion for Clojure or might it in the future?
How does autocompletion work for Lisp-like languages? I'm wondering if the verb-subject ordering makes it more difficult to build effective autocompletion.
In languages with a syntax like C, code phrases benefiting from autocompletion focus on a particular thing in subject-verb-object order:
obj.method(param);
Consequently I can engage auto-completion by typing the following, where <cursor> is the location of the text cursor in the editor:
obj.<cursor>
I type variable name and the "dot" (or equivalent), and the IDE can make informed suggestions about methods to show: methods defined on obj, or methods taking obj's type as their first input.
When writing code, I usually know what object I'm working on (autocompleting the variable name is useful but not crucial, since it's usually on preceding lines). What I want to know, and the area in which autocompletion helps me most, is finding out what methods are relevant to that specific object (e.g. defined by the object).
When I'm writing quick prototype code, I use an approach that's almost like single static assignment:
A a = new A();
B b = a.foo();
C c = b.bar();
Using autocomplete, I can explore objects and methods while staying within the IDE. When combined with in-IDE documentation, writing new code is extremely effective.
How do you effectively autocomplete in a Lisp language?
(<cursor>
If I type that, there's no object yet, so what autocompletions can show up? A list of all functions?
(<cursor> obj ...)
If I type this line and move my cursor back to the first parenthesis, then it makes sense that autocompletion could understand the context, but moving the cursor backwards is inconvenient. It's not a fluent way to write code.
I have not used autocompletion in Lisp-based languages. How do IDEs or REPLs solve this problem? It seems like a similar problem will affect pure-style functional programming languages like Haskell. Static typing is not the criterion, since Python has effective REPL autocompletion.
Does the lack of a natural opportunity to present relevant autocompletion information inhibit the development of advanced editors for these languages?
I'm not sure how LightTable works, but I can talk about how it works in Cursive. There's really not a lot of magic but there are a lot of tricky details. It seems like you're mostly talking about object method calls there - you're right that in the most common case (start typing the method name without putting the object after it first) you really can't do much. Currently in that case we propose all methods for all available classes, which is everything in java.lang and everything that's imported - I think most Clojure solutions do this. However this still misses some cases like (warning: totally invented api):
(let [entry (.getEntry my-map)
key (.getK|
Here you can't easily tell that you want the key of your map entry here since the MapEntry class isn't imported. I'm planning some improvements where I'll walk up the AST from the completion point and get the types of all variables on the way and propose all methods from them, but that requires type inference which I don't have yet (although it's on the list). IntelliJ has also really shown how you can push the bar here with some lateral thinking, they propose chained method calls etc based on the type, so there's a lot of cleverness you can do with a little thought (and a good test suite).
Completion for functions etc is obviously easier although in the case of protocols the problem is similar - you'll get all the protocol methods suggested since they're just fancy functions, but you won't get proper context-sensitive completion unless you've put the object implementing the protocol after the symbol you're completing - the most you can hope for is some sort of error message later that what you've entered doesn't look consistent.
Edit: one thing I forgot to mention is that in the completion list for methods we show the full signature as well as the list of all classes that have a method with that signature, which helps a lot in choosing the right method.
Erik Meijer has complained about this in the past. The answer is that it require a change in thinking. Object-oriented programming encourages the programmer to think about objects first (duh) and later ask what methods are available to them. Functional programming is the opposite. You think of the verbs first; the nouns themselves are interchangeable. So the simple answer is this:
(fo<cursor>
Pressing tab (or whatever invokes your auto-complete) would pop up a list of options such as this:
(foo
(foo-bar
(foo-bar-baz
As for exploration, Clojure has tools such as doc and find-doc to help you search for a particular function.
So the noun is encoded after the verb. I've seen scheme libraries like this, and makes me wonder there really are some non trivial purely verb libraries out there for functional languages?
Although I see your point, I think it's being a bit unfair because I could tell you the same thing:
new <cursor>
What would tab show you? All the possible objects?
You at least need a base to get started.. in lisp, it's not uncommon to have functions defined as (character-move), so (character-<tab>) works well. But even without that, since lisps use functions at its root instead of objects, it makes sense to know the ones you want to use.
Comments
Does LightTable have autocompletion for Clojure or might it in the future?
How does autocompletion work for Lisp-like languages? I'm wondering if the verb-subject ordering makes it more difficult to build effective autocompletion.
In languages with a syntax like C, code phrases benefiting from autocompletion focus on a particular thing in subject-verb-object order:
Consequently I can engage auto-completion by typing the following, where <cursor> is the location of the text cursor in the editor: I type variable name and the "dot" (or equivalent), and the IDE can make informed suggestions about methods to show: methods defined on obj, or methods taking obj's type as their first input.When writing code, I usually know what object I'm working on (autocompleting the variable name is useful but not crucial, since it's usually on preceding lines). What I want to know, and the area in which autocompletion helps me most, is finding out what methods are relevant to that specific object (e.g. defined by the object).
When I'm writing quick prototype code, I use an approach that's almost like single static assignment:
Using autocomplete, I can explore objects and methods while staying within the IDE. When combined with in-IDE documentation, writing new code is extremely effective.How do you effectively autocomplete in a Lisp language?
If I type that, there's no object yet, so what autocompletions can show up? A list of all functions? If I type this line and move my cursor back to the first parenthesis, then it makes sense that autocompletion could understand the context, but moving the cursor backwards is inconvenient. It's not a fluent way to write code.I have not used autocompletion in Lisp-based languages. How do IDEs or REPLs solve this problem? It seems like a similar problem will affect pure-style functional programming languages like Haskell. Static typing is not the criterion, since Python has effective REPL autocompletion.
Does the lack of a natural opportunity to present relevant autocompletion information inhibit the development of advanced editors for these languages?
I'm not sure how LightTable works, but I can talk about how it works in Cursive. There's really not a lot of magic but there are a lot of tricky details. It seems like you're mostly talking about object method calls there - you're right that in the most common case (start typing the method name without putting the object after it first) you really can't do much. Currently in that case we propose all methods for all available classes, which is everything in java.lang and everything that's imported - I think most Clojure solutions do this. However this still misses some cases like (warning: totally invented api):
Here you can't easily tell that you want the key of your map entry here since the MapEntry class isn't imported. I'm planning some improvements where I'll walk up the AST from the completion point and get the types of all variables on the way and propose all methods from them, but that requires type inference which I don't have yet (although it's on the list). IntelliJ has also really shown how you can push the bar here with some lateral thinking, they propose chained method calls etc based on the type, so there's a lot of cleverness you can do with a little thought (and a good test suite).Completion for functions etc is obviously easier although in the case of protocols the problem is similar - you'll get all the protocol methods suggested since they're just fancy functions, but you won't get proper context-sensitive completion unless you've put the object implementing the protocol after the symbol you're completing - the most you can hope for is some sort of error message later that what you've entered doesn't look consistent.
Edit: one thing I forgot to mention is that in the completion list for methods we show the full signature as well as the list of all classes that have a method with that signature, which helps a lot in choosing the right method.
Erik Meijer has complained about this in the past. The answer is that it require a change in thinking. Object-oriented programming encourages the programmer to think about objects first (duh) and later ask what methods are available to them. Functional programming is the opposite. You think of the verbs first; the nouns themselves are interchangeable. So the simple answer is this:
Pressing tab (or whatever invokes your auto-complete) would pop up a list of options such as this: As for exploration, Clojure has tools such as doc and find-doc to help you search for a particular function.So the noun is encoded after the verb. I've seen scheme libraries like this, and makes me wonder there really are some non trivial purely verb libraries out there for functional languages?
Although I see your point, I think it's being a bit unfair because I could tell you the same thing:
What would tab show you? All the possible objects?You at least need a base to get started.. in lisp, it's not uncommon to have functions defined as (character-move), so (character-<tab>) works well. But even without that, since lisps use functions at its root instead of objects, it makes sense to know the ones you want to use.