Unify conversions of polyglot values entering Enso engine into a single Node implementation

[wdanilo]

This task is automatically imported from the old Task Issue Board and it was originally created by jaroslavtulach.
Original issue is here.

---

While working on #183000876 it come to my attention that there are two similar, yet different nodes performing a very important functionality:

• CoercePrimitiveNode
• HostValueToEnsoNode
• moreover there is now also a third one - CoerceNothing.

At various places we are using different combinations of these nodes. That results in inconsistencies in treating foreign values. Some may be converted when passed as parameters, but not converted when obtained from a method or read from an array. We have to unify all these boundary conversions into a single Node and use it everywhere.

This is closely related to runtime type system (not the one @ekmett is working on, internal to Enso engine). We have to guarantee the conversion node accepts all interop valid values and makes sure all of them are consistently converted to on of Enso supported types.

Btw. rule of Truffle Interop is: delay conversions of TruffleObject instances as long as possible. CoercePrimitiveNode does convert - e.g. it is probably not the right approach and HostValueToEnsoNode is better.

Comments:

Just to clarify - CoerceNothing was introduced separately because CoercePrimitiveNode is in epb and the former needs Nothing. (Hubert Plociniczak - Sep 13, 2022)

---

Can the dependency of epb be reverted? E.g. move all the code into `runtime` and only leave the language registration in the `runtime-language-epb`? Then we wouldn't have to have two conversion nodes and could unify around a single node to convert it all. EPB isn't the only place that requires conversions. Array, Vector builtins, Java inteorp need that as well. (jaroslavtulach - Sep 15, 2022)

---

[JaroslavTulach]

Both of these nodes still seem to be present in our code base. The fact that these nodes aren't unified has already caused a problem:

• Fix matching JS strings #9203
• the solution wasn't a unification of the two nodes, but
• rather complicating code in StringLiteralBranchNode

[JaroslavTulach]

Regardless of unification, this is an interesting assert we should add:

diff --git engine/runtime/src/main/java/org/enso/interpreter/node/callable/dispatch/CurryNode.java engine/runtime/src/main/java/org/enso/interpreter/node/callable/dispatch/CurryNode.java
@@ -105,6 +109,7 @@ public class CurryNode extends BaseNode {
     if (appliesFully) {
       if (!postApplicationSchema.hasOversaturatedArgs()) {
         var value = doCall(frame, function, callerInfo, state, arguments);
+        assert isValidEnsoValue(value) : "Unexpected value " + value;
         if (defaultsExecutionMode.isExecute()
             && (value instanceof Function
                 || (value instanceof AtomConstructor cons
@@ -161,4 +166,24 @@ public class CurryNode extends BaseNode {
       default -> loopingCall.executeDispatch(frame, function, callerInfo, state, arguments, null);
     };
   }
+
+  private boolean isValidEnsoValue(Object value) {
+    if (value instanceof TruffleObject) {
+      return true;
+    }
+    if (value instanceof Boolean) {
+      return true;
+    }
+    if (value instanceof Long) {
+      return true;
+    }
+    if (value instanceof Double) {
+      return true;
+    }
+    var ctx = EnsoContext.get(this);
+    CompilerDirectives.transferToInterpreter();
+    var type = value != null ? value.getClass().getName() : "null";
+    var msg = "Unexpected value " + value + " type " + type;
+    throw ctx.raiseAssertionPanic(this, msg, null);
+  }
 }