Builtin Array Is Exposing Nulls to Surface Language

[wdanilo]

This task is automatically imported from the old Task Issue Board and it was originally created by Radosław Waśko.
Original issue is here.

---

General Summary

It is possible to encounter pure null values in the surface language if Array elements are accessed when they are not initialized.

Steps to Reproduce

1. Launch enso repl.
2. Do the following steps and observe the output:

> a = Array.new 1
>>> Nothing
> b = a.at 0
>>> Nothing
> IO.println b
null
Evaluation failed with: java.lang.NullPointerException
java.lang.Exception: java.lang.NullPointerException
    at org.enso.interpreter.runtime.callable.atom.Atom.lambda$toString$0(Atom.java:80)
    at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    (...)

Expected Result

nulls should not leak to the user. Printing missing values should not result in a crash.

Array API should be designed in such a way to never expose pure nulls to the user.

Actual Result

An exception is thrown.

Enso Version

Enso Launcher
Version:    0.2.0
Built with: scala-2.13.3 for GraalVM 20.2.0
Built from: enso-0.2.0 @ d2df28bc43fcfee614fb31780cd46a59ebb16127
Built on:   Linux (amd64)
Current default Enso engine: 
Enso Compiler and Runtime
Version:    0.2.2-SNAPSHOT
Built with: scala-2.13.3 for GraalVM 20.2.0
Built from: wip/rw/database-library* @ 7e9d7e0ef10a609ead816375386b86f473219bcd
Running on: OpenJDK 64-Bit Server VM, GraalVM Community, JDK 11.0.8+10-jvmci-20.2-b03
            Linux 4.15.0-132-generic (amd64)

Migrated from #1424

[JaroslavTulach]

With 4dcf802 I am getting the exception even sooner:

enso$ ./built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/bin/enso --repl
a = Array> a = Array.new 1
>>> Nothing
> b = a.at 0
Evaluation failed with: Null receiver values are not supported by libraries.
java.lang.Exception: Null receiver values are not supported by libraries.
        at com.oracle.truffle.api.library.LibraryFactory.dispatch(LibraryFactory.java:528)
        at com.oracle.truffle.api.library.LibraryFactory.create(LibraryFactory.java:295)
        at org.enso.interpreter.runtime.error.WarningsLibraryGen$CachedDispatch.specialize(WarningsLibraryGen.java:542)
        at org.enso.interpreter.runtime.error.WarningsLibraryGen$CachedDispatch.hasWarnings(WarningsLibraryGen.java:492)
        at org.enso.interpreter.runtime.data.Array.hasWarningElements(Array.java:160)
        at org.enso.interpreter.runtime.data.Array.hasWarnings(Array.java:170)

[JaroslavTulach]

I have a fix:

• Avoid nulls in Array.items #5736

but there is a question puzzling in my mind: What's the point of having Array.new size now, when there is no set method and Array is immutable!? CCing @jdunkerley and @radeusgd

[jdunkerley]

but there is a question puzzling in my mind: What's the point of having Array.new size now, when there is no set method and Array is immutable!? CCing @jdunkerley and @radeusgd

A fair question - we still have Array in a couple of places, but we should probably reduce this. There are 2 places we use Array.copy to fill it.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-02-22):

Progress: - Array.allocate: bb03d51

• Don't ignore executionStatus messages: Don't let the IDE throw away executionContext/executionStatus messages #5734
• Table.Value suggestion: Dropdown for Table.join right is wrong #5055 (comment)
• fixing node.js dependencies: Fixing the node.js dependencies, so the VSCode plugin can be built again #5738
• standup: discussing NaN.ordering
• simplify sbt development: No need for -- when using withDebug command #5737
• 1:1 meetings, standups, retros It should be finished by 2023-02-22.

Next Day: Dropdown for Table.join right is wrong