Remove the need for `import Standard.Visualization` from user code

[JaroslavTulach]

• Investigate what would it take to remove import Standard.Visualization from the user Main.enso module?
• the IDE is executing visualizations via language server protocol
• since Evaluate visualization arguments in the Main module #13342 the visualization configuration with method pointer doesn't need Standard.Visualization import
• however there is "the else branch"

Trying It

Removing import Standard.Visualization from a file right now results in:

[execution.JobExecutionEngine] Executing job: org.enso.interpreter.instrument.job.ExecuteEx
pressionJob@76950808...
[execution.JobExecutionEngine] Executing job: ExecuteJob(contextId=e000f57a-4ab1-4105-9450-
de9f27288938, jobId=4966132d-77b7-4227-a900-cc78dda746bf)...
[job.ExecuteJob] Starting ExecuteJob[4966132d-77b7-4227-a900-cc78dda746bf]
[enso.org.enso.compiler.Compiler] ESC[1mlocal.NewProject1.Main:1:10: ESC[31merror: ESC[0mFully qualified name references a l
ibrary Standard.Visualization but an import statement for it is missing.
[job.ProgramExecutionSupport$] Execution of visualization [27336da8-8d7b-4d16-bec8-7ca0dfb93
281] on value [e847305d-6ac9-4243-a87c-3cf242cd519e] of [Nothing] failed. Compile error: Fully qualified name references a library Standard.Visualization but
 an import statement for it is missing. | Nothing | {}
org.enso.interpreter.runtime.error.PanicException: Compile error: Fully qualified name references a library Standard.Visualization but an import statement fo
r it is missing.
[job.ProgramExecutionSupport$] Error at 9-22 (e.g. `Visualization`) of 27336da8-8d7b-4d16-bec8-7ca0dfb93281 with text:
Standard.Visualization.Table.Visualization.prepare_visualization _ (1000) <| column4 * 3
[command.Command] Executing command asynchronously: DetachVisualizationCmd...

when trying to invoke (*) multiply on a Column with numbers.

Ideas to Fix It

Inline & Imports (rejected)

@farmaazon suggested to Maybe the "expression" should allow imports?

We tried to make that happen, but never succeeded:

• the design we inherited doesn't allow that
• imports are always global to the module (e.g. .enso) file
• expression is inline evaluated in the context of the module
• if it defined its own imports
• the whole module interpretation could completely change

We don't know how to prevent the complete change of interpretation. Hence this idea is on hold for few months already.

FQN + Preload (to investigate, if Lazy FQN Import as defined below fails)

@farmaazon wrote:

• With this Standard.Visualization import, the engine knows that we use this library.
• ... the fully qualifed name could work ...
• ... Actually, we already call with FQN

• let's modify the language server to tell the engine to
• preload Standard.Visualization into the top scope via a new option "enso.prelude.libs"
• when an import from one of the preloaded libraries is found
• turn it into a warning only
• then visualization code could use FQN to reference Standard.Visualization library without import statement in Main.enso

Lazy FQN Import (to investigate)

• allow FQN without import - don't error
• resolve them lazily when execution reaches that statement
• this would help PoC: Getting Any, Text & numbers closure down to 35 modules #12819 - especially it also worked with project. prefix
• maybe a new option ALLOW_UNRESOLVED_FQNS? Or re-use STRICT_ERRORS?
• FQN checked when --enable-static-analysis - then they yield errors