Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically force all-defaulted functions #3414

Merged
merged 17 commits into from
Apr 27, 2022
Merged

Conversation

kustosz
Copy link
Contributor

@kustosz kustosz commented Apr 22, 2022

Pull Request Description

This changes the interpreter to treat functions with all-defaulted args as thunks. Seems to have no performance impact in compiled code.

Important Notes

Checklist

Please include the following checklist in your PR:

  • The documentation has been updated if necessary.
  • All code conforms to the Scala, Java, and Rust style guides.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed: Enso GUI was tested when built using BOTH ./run dist and ./run watch.

Comment on lines 94 to 96
| foo f = f 1
| bar x=1 = x + 1
| foo (bar ...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nitpick but I'd suggest making the argument passed to f have different value than the default one - this way we ensure that we do not get some weird behaviour where the default one was used instead (it seems extremely unlikely to get a bug with such behaviour, but you never know and the cost of testing this case is 0 as we just need to change this value).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I wouldn't call it "extremely unlikely" given the behavior I saw in the process of implementing this, and I would call the test as it exists "extremely bad at testing things" :P

Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it runs fast, then it is probably good enough. As I don't yet understand the code base much, I provided some general comments and few questions. I see no problem integrating the request.

limit = Constants.CacheSizes.THUNK_EXECUTOR_NODE)
Stateful doCached(
Thunk thunk,
Function thunk,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit pick: does the variable still deserve name thunk when it's type is now Function?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that thunk.isThunk is a bit confusing :)


@Specialization(
guards = {"!fn.isThunk()", "fn.isFullyApplied()", "isTail == cachedIsTail"},
limit = "3" /* limit is 3 because that's the number of different values for isTail */)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One could define

  static int numberOfDifferentValuesForIsTail() {
    return BaseNode.TailStatus.values().length;
  }

and then use

Suggested change
limit = "3" /* limit is 3 because that's the number of different values for isTail */)
limit = "numberOfDifferentValuesForIsTail()"

val dependencies = depInfo.dependencies

// The test for dependents
dependents.getDirect(argXId) shouldEqual Some(Set(xUseId))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity: Why the changes in this test have to be made? Is it because of changes in DemandAnalysis?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's a horrible terrible spec and honestly I had to stop myself nuking the whole file. So the problem here is, these stupid pass specs use previous passes to build the initial test state. So, demand analysis runs before this, so the input IR for this spec changes and now it blows up. We should discuss this, but IMO in the near future we need to either nuke all of these specs, or rewrite them to be self-sufficient.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the IR serializable? If so, we can serialize the input into a file and read it.

limit = Constants.CacheSizes.THUNK_EXECUTOR_NODE)
Stateful doCached(
Thunk thunk,
Function thunk,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that thunk.isThunk is a bit confusing :)

@JaroslavTulach
Copy link
Member

Reviewed again. Looks sane.

@kustosz kustosz added the CI: Ready to merge This PR is eligible for automatic merge label Apr 27, 2022
@mergify mergify bot merged commit 96a0c92 into develop Apr 27, 2022
@mergify mergify bot deleted the wip/mk/fix-all-defaults branch April 27, 2022 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants