Correct expression updates of partially applied constructors

[4e6]

Pull Request Description

close #6903

Works this way:

• Detect the call to the constructor on function enter
• On the expression return, check if it was a partially applied constructor call. Then build the function info from the resulting function

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,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.

[JaroslavTulach]

As written here:

I believe we are trying to tackle the problem from a wrong angle. What's the goal? When there is a partially applied function, then we want to know what arguments have been applied. That is not information about "a call" that has happened, but about a "future call" - we have a function value and the IDE needs to know what to do with it.

That means (in my opinion) that ProgramExecutionSupport.scala needs to do following when composing sendExpressionUpdate:

• when the value.getType is Standard.Builtins.Main.Function
• accompany the information with a MethodPointer to the function definition
• use (value.value : runtime.Function).getSchema() to obtain hasPreApplied array and send it to the IDE somehow

I don't think the IdExecutionInstrument shall differentiate between constructors and other executables. The solution presented in this PR continues to push the solution in the wrong direction - at least according to my opinion. Or I am completely confused. In any case I cannot approve it.

[4e6]

• If we just detect that the expression returns a function (on the expression return), we don't have enough information to build a method pointer from it. It has to be captured (and stored) before (on the function call return)
• Expression update contains information about the computed expression, not the expression that will be computed.

main =
    x1 = func1 1
    x1

func1 x = func2 x
func2 x y z = x + y + z

Following your logic, the expression update of the func1 1 will return arguments of the func2 call.

[JaroslavTulach]

@Frizi wrote:

If you are able to ... fill methodPointer (or a function schema for that matter) before actual execution, the IDE should be ready to accept it

Pawel also noted that the current implementation is a significant source of buggy behavior:

this behavior is also a cause of some issues during graph reevaluation, where new Pending updates are setting methodPointers to null, causing widgets and arguments to disappear for a moment

Based on that I request changes. We don't want any more workarounds in IdExecutionInstrument - we want to make sure that ProgramExecutionSupport.sendExecutionUpdates sends info about Function values to the IDE. Tracked as

• Send info about function values to the IDE #6957

[4e6]

Pawel is talking about sending the method pointers in the compile time when the Pending updates are sent. It has nothing to do with this change.

Regarding his idea. The engine doesn't have sophisticated enough static analysis to do that right now. What IDE can do is preserve the information about the method pointer when it receives the Pending update instead of erasing all the information about the node. I assume erasing only the type information should be enough to gray out the nodes

[4e6]

Superseded by #6957

[JaroslavTulach]

Pawel is talking about sending the method pointers in the compile time when the Pending updates are sent.
It has nothing to do with this change.

Yeah, now I get it too. Enso doesn't have a static type checker. The only thing we can do is to deliver the information during runtime. We just have to make sure we deliver the right information as #6957 suggests.