Offer "import library hint" when needed

[JaroslavTulach]

A discussion is raging on about improving the way we deal with imports. It is a complex topic that cross cuts many areas and as such it is hard to grasp it and narrow it to something manageable. During one sleepless new year's night I had a dream that changed it all! We already have all the pieces ready, we just need a UI to glue them together!

The picture shows a simple project demonstrating what happens when one references a library type without importing it. All the information is there:

• the component node already properly displays error
• the error clearly identifies a fix to apply to resolve it
• e.g. it suggests to add import Standard.Table to the top of the file

Could the IDE add a Quick fix button "Import library" hint to the end of the error message? After clicking the button the IDE would add import Standard.Table at the top of the file. Is that possible, easy to try, @vitvakatu?

If such a quick fix button was possible, it would be a great proof of possibility of import management and a fantastic tool to play with the overall system and discover what else needs changes and improvements to bring import management up to the high expectations of a dynamic live coding language like Enso!

[JaroslavTulach]

Prior Art

I believe we are all used to our IDEs to help us managing imports. Having such a quick fix hint shouldn't be really surprising even in Enso IDE.

[JaroslavTulach]

Why is Import Management Needed?

• one of the most important goals is Launching Enso programs instantly #10121
• number of import statements in an empty project influences the initialization time
• compare main = IO.println "Hello World" with only import Standard.Base.IO or with from Standard.Base import all:
  • 1,2s over no import startup as the hello_world_startup benchmark shows
  • 1.7s over no import startup as the hello_import_startup benchmark shows
  • clearly processing imports isn't for free
• moreover the new project (as generated by the IDE currently) includes everything!

from Standard.Base import all
from Standard.Table import all
from Standard.Database import all
from Standard.AWS import all
from Standard.Google_Api import all
from Standard.Microsoft import all
from Standard.Snowflake import all
from Standard.Tableau import all
import Standard.Examples
import Standard.Visualization

Conclusion: We have to stop over importing if we want to be fast!

[farmaazon]

One note here: currently our implementation of imports is very granular, i.e. we import exactly one name we need for a particular entity. But if we want to keep the number of imports minimal, we should rather make use of this "import all", so we will have one import from, for example, Standard.Base, instead of ten.

[JaroslavTulach]

imports is very granular, i.e. we import exactly one name we need for a particular entity

I don't think there is anything bad on it!

• the problem isn't the number of import statements
• the problem is the transitive closure of all modules that need to be processed
• e.g. from Standard.Base import all is very costly
• importing import Standard.Base.IO is cheaper
• even ten imports from Standard.Base is cheaper than all

Moreover there is an issue of clarity:

• the import all brings in many symbols automatically
• doing so from multiple libraries may cause conflicts
• especially when one upgrades to new version of the system which ...
• ... very likely adds new symbols into its libraries a clash cannot be prevented

The only problem with explicit imports is that they are verbose and harder to manage. However if an IDE handles them for the user automatically, then I'd say: prefer explicit imports (btw. I even forced NetBeans team to make explicit the default).

[JaroslavTulach]

Suggestion DB

Of course, the next level would be to consult Suggestion DB and insert fully qualified import statement. I believe all the necessary information is already provided in the Suggestion DB, right @4e6? E.g. one can query suggestion DB for all symbols named Row and select the best way to import each of them.

[farmaazon]

It's nothing new for GUI, as the Component Browser had auto-importing. The old version could even recognize partially-written fully qualified name, display all entries that matches, and after picking an entry add a proper import. But then the product team decides, that this is too advance a feature to be presented in Component Browser.

[radeusgd]

The data link mechanism also 'knows' which library provides the data link, but if it's not loaded the best it can do is display an error telling the user to add the missing import (that contains all the logic needed to 'decode' the given data link):

This mechanism would benefit the data links a lot, by allowing such error to be accompanied with a 'Quick fix' button that will then enable the 'missing' data link and let the user easily continue the work.

[JaroslavTulach]

It is great to hear yet another use-case could benefit from this "fix an error by importing something" scenario!

For the beginning the IDE could just parse the message and search for Standard.Xyz when adding the "Import Standard.Xyz" button.

Later we should standardize it all a bit:

• have a common error Missing_Import
• explicitly name the library name in the error atom
• plus provide additional human readable name in the error atom
• deliver both pieces of the information to the IDE

So IDE doesn't have to parse the message, but can use the name of the library directly.

[4e6]

the next level would be to consult Suggestion DB and insert fully qualified import statement. I believe all the necessary information is already provided in the Suggestion DB

@JaroslavTulach yes, the suggestions database contains the module where symbol is defined as well as the topmost module re-exporting the symbol.

[JaroslavTulach]

What suggestion DBs do we provide to the IDE? When there is just:

from Standard.Base import all

would the IDE obtain just suggestions for Standard.Base or also suggestions for other libraries? Those that are eligible for additional import?

If just Standard.Base is currently being sent, would it be possible to deliver suggestions for all the libraries in the edition? Maybe not at startup, but later?

[JaroslavTulach]

Looks like nobody objects against the "Quick fix" button. Now we have just a small "technical" problem: we need somebody who's going to do it. @vitvakatu, guys, do you know where is the code that displays:

Compile error: The name could not be found and adds the "copy icon"? Do you know where is the code that adds the import? With such hints I could even try to connect these two...

[farmaazon]

The display itself is GraphNodeMessage component.

The message is specified in GraphNode.

The current implementation of adding imports is addMissingImports in graph store - usage example here. But this allows only imports of a single name; if you would like to keep the number of imports minimal, we should at some point fold several imports from the same library.

How to deduce what import to add for given name? First, you can look up all suggestions with the name using "conflictingName" index in our SuggestionDb. Then, you may use requiredImports to get imports needed for this entry. I'm not sure if we support direct imports of static methods, though.

Feel free to just make an issue for us - but I'm not sure when it would be taken, as we have plenty of things to implement in Q1

[JaroslavTulach]

Thanks a lot for your help Adam. Here is the rough PR for your initial review:

• Quick Fix Import Button #12051