Builtins expose Enso methods #11687

Akirathan · 2024-11-27T19:00:38Z

Pull Request Description

Builtin types expose methods via the interop protocol. In fact, all types expose methods via interop protocol.

To get and invoke a method on a builtin object via interop protocol:

var meta = interop.getMetaObject(text);
meta.invokeMember(meta, "+", ...);

Example in InvokeBuiltinMethodViaInteropTest

To get and invoke a method on a builtin object via org.graalvm.polyglot.Value (this can be done, e.g., in std libs in Java code):

Value object;
Value meta = object.getMetaObject();
meta.invokeMember(...);

Example in BuiltinTypesExposeMethodsTest.

Important Notes

Method members are reported in Type.getMembers as internal members.
This has a side effect that in the debugger, types have method properties (but not atoms):

The first attempt to implement hasMember and getMembers on BuiltinObject abandoned - #11687 (comment)

Checklist

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

The documentation has been updated, if necessary.
Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
All code follows the
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
Unit tests have been written where possible.
If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
or the Snowflake database integration, a run of the Extra Tests has been scheduled.
- If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

…ble member

…bject

No longer true what this test tested

…th members

Akirathan · 2024-12-04T19:36:27Z

...ntime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/EqualsComplexNode.java

@@ -543,6 +543,12 @@ boolean isObjectWithMembers(Object object, InteropLibrary interop) {
    if (interop.isTime(object)) {
      return false;
    }
+    if (interop.isDuration(object)) {


Both TimeZone and Duration now have members, so we need to add these guards here.

The whole EqualsXyzNode set of @Specialize annotation is fragile, unreadable, not fully testable and deserves a rewrite. At least that's the feeling I get every time I am changing the code.

Such a gentle change is OK, unless total rewrite is attempted.

See my answer in #11687 (comment) - yes it is a mess.

Akirathan · 2024-12-12T18:34:24Z

Trying to first integrate #11835 seems like a dead end. Let's rather try a different approach - builtin objects do not expose members, but their types do. 752ac90 starts to implement hasMember and getMembers on a Type so that it returns methods as invocable members.

Akirathan · 2024-12-12T18:39:23Z

the
#11589 issue started with three examples of missing builtin methods
shall we not fix some of these cases in this PR?

@JaroslavTulach Ref.get, Vector.to_text, and File.path mentioned in #11589 (comment) tested in InvokeBuiltinMethodViaInteropTest

Akirathan · 2024-12-13T13:58:10Z

BuiltinObject super class split into a separate PR - #11861

JaroslavTulach · 2025-01-07T05:31:14Z

@Akirathan can you merge in the most recent develop branch? Then we can check and see what can be done with the rest...

# Conflicts: # engine/runtime-integration-tests/src/test/java/org/enso/example/PolyglotTestClass.java # engine/runtime-integration-tests/src/test/java/org/enso/interpreter/test/builtins/BuiltinsJavaInteropTest.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/builtin/BuiltinObject.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoDate.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoDateTime.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoDuration.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoFile.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoTimeOfDay.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/EnsoTimeZone.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/ManagedResource.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/Ref.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/hash/EnsoHashMap.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/vector/Array.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/vector/ArrayLikeHelpers.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/data/vector/Vector.java # engine/runtime/src/main/java/org/enso/interpreter/runtime/warning/Warning.java

JaroslavTulach

The idea of using static methods on Type seems to be a great solution to all the problems we had so far. The PR is simple and unlocks a functionality that was clearly missing.

cannot call Ref.get: https://github.com/enso-org/enso/pull/11577/files#r1848224116
cannot call File.path on EnsoFile
cannot call to_text on Vector - discovered while working on Warnings displayed after main exit do not use defined to_text #11569

Can you simplify these three known workarounds in the production code as well? Then this PR will immediately be useful for Enso users!

JaroslavTulach · 2025-01-10T15:51:21Z