Adopting GraalVM's support for BigInteger

[JaroslavTulach]

Pull Request Description

Fixes #7213 by reacting to new isBigInteger and asBigInteger messages. Adjusts tests to require BigInteger when appropriate. EnsoBigInteger no longer extends Number. Enso tests to come.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• All code follows the
  Scala,
  Java,
• All code has been tested:
  • Unit tests have been written where possible.

[JaroslavTulach]

Currently there is 40 errors like this one where the precision of a number changes.

[JaroslavTulach]

Alas, GraalPython currently doesn't support BigIntegers:

diff --git test/Tests/src/Data/Numbers_Spec.enso test/Tests/src/Data/Numbers_Spec.enso
index 592bc7ac99..7b4879de67 100644
--- test/Tests/src/Data/Numbers_Spec.enso
+++ test/Tests/src/Data/Numbers_Spec.enso
@@ -835,6 +835,8 @@ spec =
         bigint_spec "Enso" (x->x) (*)
         bigint_spec "Java" to_java_bigint java_bigint_mul
         bigint_spec "JavaScript" to_js_bigint js_bigint_mul
+        if Polyglot.is_language_installed "python" then
+            bigint_spec "Python" to_python_bigint python_bigint_mul
 
 main = Test_Suite.run_main spec
 
@@ -844,3 +846,9 @@ foreign js to_js_bigint n = """
 
 foreign js js_bigint_mul a b = """
     return BigInt(a) * BigInt(b)
+
+foreign python to_python_bigint n = """
+    return int(n)
+
+foreign python python_bigint_mul a b = """
+    return int(a) * int(b)

fails. With oracle/graalpython#346 the Python test seems to pass OK.

[JaroslavTulach]

Engine (linux) and also Windows runs are fine. Time to address the change requests, fix minor issues and integrate. Engine code owners, please review.

[JaroslavTulach]

Thank you for your reviews. Let's execute benchmarks and if they are OKeyish, integrate. There is also second run and 3rd run to see the trends.

Most of the Results seem fine. There is small slowdown in equalsString:

it'd be acceptable. However there is more than 10% slowdown in caseBench3 and it will need some investigation:

smaller slowdowns are also visible in caseBench6, ifBench3. Some VectorBenchmarks_averageOver benchmarks are also affected - probably result of the previous case and if slowdown.

On a positive side. The StringBenchmarks_lengthOfStrings got 3% faster.

[radeusgd]

Can't wait to get this in and being able to move forward with stuff like #7354

[JaroslavTulach]

Re. bench_case3 benchmark. There seems to be a difference in HostValueToEnsoNode.fallbackGuard.

The difference adds one additional if check which may be the reason for the slowdown. On the other hand, it is all a bit strange. Why shall we use HostValueToEnsoNode at all? It is used from Vector:

    fold : Any -> (Any -> Any -> Any) -> Any
    fold self init function =
        f = acc -> ix -> function acc (self.at ix)
        0.up_to self.length . fold init f

and all the values are coming from Enso. Very likely this is caused by defensive check - we can certainly do better if we know the Vector contains only Enso values. Let's leave this for

• Unify & speed access to array-like objects behind ArrayXyzNode #6299

[JaroslavTulach]

Can't wait to get this in and being able to move forward with stuff like #7354

Let's get this in. Benchmark slowdowns will be investigated later - especially in #6299.