expressionUpdates do not contain Method Pointer of operators.

[farmaazon]

I have a project, where next to the starting "Press tab to..." node, I added 3 + node.

Then I inspected the network tab and look through "expressionUpdate" messages IDE had received from the engine. No expression contained a method pointer for "+" operator (there was no "+" character in all messages).

3 + _ or even 3 + 4 also had no method pointer. Tested on 2023.2.1-nightly.2023.8.4 engine.

This task is blocking #7107. The IDE implementation is on branch wip/farmaazon/placeholders-for-operators - you can test if your fix makes the argument names appear in nodes like 3 +.

[hubertp]

This is slightly confusing since it should have been fixed in https://github.com/enso-org/enso/issues/6374#issuecomment-1618697451. And in fact later a separate ticket was created https://github.com/enso-org/enso/issues/7190 which blamed IDE (and the #7107 that you mention).

[4e6]

There are multiple issues.

1. The expression 3 + 4 does not return the method pointer because there is an issue with the registration of Integer.+ method. Although the method is defined in the Numbers module, it does not get picked up by the compiler https://github.com/enso-org/enso/blob/b656b336c7d239ef95a548f87deb5af2f4801368/distribution/lib/Standard/Base/0.0.0-dev/src/Data/Numbers.enso#L690-L691 The "a" + "b" expression on Text returns the Text.+ method pointer correctly.

   2. The expression "a" + is represented not as a method call but as a closure in runtime. When the method is called with the dot notation "a".+, the expression returns the Text.+ method pointer correctly. I need to check the codegen to see why it generates a closure instead of a method call. The expression 3.+ does not return a method pointer because of the issue (1) with the registration of the Integer.+ method.

[farmaazon]

I propose to fix 2 first, as it allows me to test my branch (I'll test "a" + instead of 3 +)

[hubertp]

1. The expression 3 + 4 does not return the method pointer because there is an issue with the registration of Integer.+ method. Although the method is defined in the Numbers module, it does not get picked up by the compiler https://github.com/enso-org/enso/blob/b656b336c7d239ef95a548f87deb5af2f4801368/distribution/lib/Standard/Base/0.0.0-dev/src/Data/Numbers.enso#L690-L691

@4e6 Probably related to https://github.com/enso-org/enso/issues/6959. it felt like a hack when I had to introduce this exception, now it feels even more.

[hubertp]

@Akirathan probably related to our discussion today.

[4e6]

After the investigation today, it seems like the issue (1) with the registration of Integer.+ method should be fixed by #6959. I'll check once again after it is implemented.

[enso-bot[bot]]

Dmitry Bushev reports a new STANDUP for yesterday (2023-08-23):

Progress: Started working on the issue. Started looking into the issue with the registration of an Integer.+ method. Created a test case reproducing the example. Discovered that the Small_Integer.+ method is registered instead. This issue should be fixed in 6959 It should be finished by 2023-08-28.

Next Day: Next day I will be working on the #7520 task. Continue working on the task

[enso-bot[bot]]

Dmitry Bushev reports a new STANDUP for today (2023-08-24):

Progress: Continue working on the issue. Switched to the second part of the issue with the generation of the closure node instead of a method call. Created the test reproducing the issue. Tracked down to the SectionToBinOp compiler pass. Started working on the fix. It should be finished by 2023-08-28.

Next Day: Next day I will be working on the #7520 task. Continue working on the task

[enso-bot[bot]]

Dmitry Bushev reports a new STANDUP for today (2023-08-25):

Progress: Continue working on the issue. Updated the SectionToBinOp compiler pass to generate a function application instead of a lambda for left sections. Fixed the tests. Created a draft PR. It should be finished by 2023-08-28.

Next Day: Next day I will be working on the #7520 task. Continue working on the task