How can we enhance API discoverability?

[chris-martin]

This thought is inspired by Tim Ottinger's recent Dot-Programming your Object Oriented Code and some subsequent Twitter discussion. Tim paints a pretty accurate picture of how IDEs work to great advantage in OO langs.

When you write a program, you will not read the documentation. You don't have time and inclination for that. [...] You type the name of some object and you press the dot. The list that pops up is your guide to the world of the object whose name lives on the left side of the dot you just pressed.

The discoverability is so powerful that when you pick up a new library, you often only need to read the documentation far enough to instantiate one core object, and any IDE can walk you through the rest.

Coming to haskell from OO feels like there's just a soup of functions; no context-sensitivity...
--@doublehelix

There are two big reasons I see that a naive code completion feature doesn't easily fit Haskell:

1. The workflow doesn't tend to proceed strictly left-to-right, so completion isn't as simple as just inserting at the cursor. In a haskell translation of my previous example, the code z $ y x would be written from right to left if x leads to the discovery of y and then to z.
2. What the IDE should suggest is a more complicated question. The OO case is trivial - just list the members of the type. With Haskell... I'm not even entirely sure what I'm asking for.

I think anything we can do to create a discovery experience akin to OO code completion would be a huge win.

[deech]

I feel like the equivalent in Haskell is hole driven development. Seems like in a lot of cases programatically substituting a chunk of syntax with an _ and grabbing GHC's suggestions for auto-completion would work really well. A layer above the GHC API that allowed such a operation to be driven by some front end is possible relatively easy to implement and would be immediately useful.

[acowley]

I'd like to slightly expand upon @deech's comment: the Haskell twist on dot-driven development is nonlinear hole-driven development.

You jump between different parts of a term, and possibly a type annotation for that term, refining each part a little bit at a time. Hoogle search tied to holes seems like a natural fit.

[alanz]

I think both mote and djinn address this space as well

[Profpatsch]

I had the type holes + hoogle idea a while ago, too.
Implementing a trivial compleltion should be straightforward, shouldn’t it?

1. Ask ghc for type hole at current cursor point
2. Look at the imported symbols and show the ones whose type matches

There would be pretty of optimization space for the heuristics of finding probably matches, probably even room for a few research papers. Maybe there are already some? We should look at ML or systems like Isabelle for inspiration, they are certainly doing something in that direction already.

[bitemyapp]

@alanz djinn is pretty limited, exference is better but is limited to a static universe of terms it's aware of. I have no iea about mote.

Holes have other issues, like not showing you typeclass constraints.

I like the idea in principle. Maybe let the user prompt for suggested terms, starting from most concrete, to fill a gap?

[tonyday567]

In a haskell translation of my previous example, the code z $ y x would be written from right to left if x leads to the discovery of y and then to z.

It would be useful if an ide matched right-to-left cursor movement when appropriate. So if sitting at |x y you type a $ and the result is | $ x y. With typed holes it would be _1 x y and _1 $ x y.

But this is probably too ide dependent to be in scope.