I wonder what may have changed, e.g. with the RLS and so on
basically inspired by the haskell holes workflow, imagine deliberate support for leveraging the type inference system to assist finding code. (like 'dot-autocomplete' on steroids)
and this should be a boost to the command-line edit-compile cycle, even when IDE support is flaky;
haskel-holes deals purely with types I think, but imagine if you could write a placeholder identifier, which will parse into the language's AST; the presence of any Placeholders precludes compiling a real program; the inference engine should just assume the demands from any sources/dests are met, then the compiler would report the set of functions/methods/fields that could fill that placeholder. 'dot-autocomplete' only works forward.. this could work forwards and backwards
does any of the progress with the RLS .. presumably the compiler engine has been modified since I last looked years ago with more deliberate intent toward tooling; have there been any other requests in this kind of direction ?
the tooling situation is definitely improving, IntellijIDEA support is quite good but still not as solid as C++ environments (obviously, community momentum); it's definitely one of several important factors in using the language;
I've always commented that for me, good IDE support counts for more than the language tweaks between C++ and Rust .. and yet I know that some aspects of rust e.g. context-free-grammar could yield superior tooling
I remember a while back hearing how one language had generated an index of all the available functions and would then let you search for a particular function depending on type signature. So for example, say you were looking for a way to join strings (fn (Vec<String>, String) -> String) you could plug that into a search engine and it would show functions which might be useful to you.
Kinda like how rust will say "here are some functions which might fulfill your needs...", but on steroids.
We could probably trial it in something like the RLS, and move it into the compiler as a "haskell holes"-like feature if it's found to be successful.
yes that's almost exactly what I've got in mind, except the query is built into the source code as a placeholder symbol, and takes the query from trying to match as much of the type information around it as possible. I think this would work really well with rusts idea of starting out with the function signature inputs->outputs, and you then 'fill in the blanks' to get the transformation done.
I guess it could be built as a commandline tool using the RLS (?) so that it's still available for commandline builds. I worry about flakiness setting such tools up which is why 'being built into the compiler' might be nice .. code nav should be useful to everyone, but it might take a while to refine, sure..
I remember a while back hearing how one language had generated an index of all the available functions and would then let you search for a particular function depending on type signature.
Haskell has this and it is beautiful. Hoogle for [String] -> String -> String, and the correct function is there as the second result (it's called intercalate). What's more, the function doesn't even have that signature, but rather a more general generic one, forall a. [a] -> [[a]] -> [a]. (Haskell's String is an alias for [Char])