Fix bug in QuotedOp.transform

[mabbay]

There's a bug in QuotedOp.transform, it copies the value of quotedOp, making quotedOp field value different from the op inside quotedBody.

---

Progress

• Change must not contain extraneous whitespace

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/babylon.git pull/990/head:pull/990
$ git checkout pull/990

Update a local copy of the PR:
$ git checkout pull/990
$ git pull https://git.openjdk.org/babylon.git pull/990/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 990

View PR using the GUI difftool:
$ git pr show -t 990

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/babylon/pull/990.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mabbay! A progress list of the required criteria for merging this PR into code-reflection will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@mabbay This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

Fix bug in QuotedOp.transform

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 11 new commits pushed to the code-reflection branch:

• 76e25d1: Hat replace moduleop with calldag
• 02e2f37: First section of package doc
• 4093104: [hat] refactor and simplification of ndrange
• ... and 8 more: https://git.openjdk.org/babylon/compare/2075f10395df678158dbe6e3f96f7257108f59ea...code-reflection

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the code-reflection branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 00: Full (22e08e5d)

[grfrost]

Not sure this is a good idea. I will defer to Paul.

Why not just remove the arg/param?

Sounds like are we reluctant to change the API ?

But just ignoring a param seems brittle to me. .. Maybe I am missing something.

[PaulSandoz]

The quoted operation models an embedded operation as data. In that respect there are arguably two choices as to whether a code transformer is allowed, by default, to transform that data or not. My inclination for now is to assume they can transform like for all other cases. That seems the least surprising option for now.

[mabbay]

Then we should be consistent and transform when lowering ?

[PaulSandoz]

Good question!

Lowering is a specific transformation, so we can be more opinionated in its behavior. I took the conservative position that the quoted op should not be lowered and instead copied verbatim. It is possible to quote anything, including fragments that might not make sense in the over all lowering context.

It's harder to justify that approach for lowering should be that for any transformation. More broadly I am fairly confident the lowering behavior is the right one. I am less confident as to what the right behavior should be generally, so the choice of (perceived) least surprise seems ok for now and we could revisit when we get more experience and data.

[grfrost]

My Q was more specific to the API and those exposing a call where an arg/param that is ignored seems like we need a specific one arg call..