Custom handling of warnings in method dispatch

[hubertp]

#6176 attempts to add custom handling of warning to Any. The only problem is that invocations where self has warnings is treated specially:

• we strip the warnings from the self argument by default
• we append the original warnings to the result of the invocation

There is a good reason why we do that now but it also makes the implementation of has_warnings, remove_warnings and throw_on_warning impossible on Any.
I'd really like to avoid any special handling but for example

diff --git a/engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java b/engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
index 79fddcd65..dad93e60c 100644
--- a/engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
+++ b/engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
@@ -163,11 +163,17 @@ public abstract class InvokeMethodNode extends BaseNode {
         lock.unlock();
       }
     }
+    if (!symbol.getName().equals("has_warnings")) {
+      arguments[thisArgumentPosition] = self.getValue();
+    }
 
-    arguments[thisArgumentPosition] = self.getValue();
     ArrayRope<Warning> warnings = self.getReassignedWarnings(this);
     Object result = childDispatch.execute(frame, state, symbol, self.getValue(), arguments);
-    return WithWarnings.prependTo(result, warnings);
+    if (symbol.getName().equals("remove_warnings")) {
+      return result;
+    } else {
+      return WithWarnings.prependTo(result, warnings);
+    }
   }

almost did the job. This is for illustration purposes, it's not something I would like us to adopt obviously.

Any suggestions?

[hubertp]

/cc @JaroslavTulach @kustosz

[hubertp]

Personally, I feel like we would need to have some way of marking self so that we remove/add warnings on demand to it. Similarly to how ~ controls if the argument is suspended or not.

[kustosz]

I would suggest going the same route we do with Error. For the purposes of method dispatch, a dataflow error is not an Any and we abuse it to implement things like catch etc. You could do something similar here – define methods on a type, like Warned and then method dispatch for a warned value would be something like:

1. If the method exists on Warned, call it
2. Otherwise delegate dispatch to to the wrapped value, with the current re-wrapping dance we have in place.