Earlier quoted context omitted.
these functions' documentation is either buried in a long manual This is a problem with lots of feature-rich software, even with meticulously-documented APIs. What we need is reverse-indexed documentation. That is, an extensive API reference is only useful for someone who already knows what functions are in the API and just needs to remember how to use them. But even the most thorough API reference does nothing to pr…
One great approach is the Hoogle search engine for Haskell [1]. The idea with that is that you search by type, instead of name. So if you were looking for a function to take a item, and return a list with n copies of that item, you would search for `a -> Int -> [a]`, which would give you back replicate. Looks like the Nix expression language is untyped, so this wouldn't work directly, but maybe adding a rough type si…
The way it works is you write a sequence of arguments and an expected result, and it suggests a method to call.
For example, I just now tried it, entering
3. 4. 7
in the input. It suggested the following methods: 3 + 4 --> 7
3 bitOr: 4 --> 7
3 bitXor: 4 --> 7
Clicking on any of these opens a browser on the class and method concerned.Another example: input of
'hello world'. #('hello' 'world')
yielded the single suggestion 'hello world' substrings --> #('hello' 'world')
Another: ' abc '. 'abc'
yields ' abc ' asLegalSelector --> 'abc'
' abc ' withBlanksTrimmed --> 'abc'
;;--It's a total hack, of course, but none the less effective or useful for that.
It has a list of methods marked "safe to experiment with", and simply tries them out.
It gets a big boost from being able to evaluate the receiver (the first in the input list) to a concrete object, and then only consider methods on that object's class.