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

Rewrite applied LET/INs in the builder #2536

Merged
merged 6 commits into from
Apr 17, 2023
Merged

Rewrite applied LET/INs in the builder #2536

merged 6 commits into from
Apr 17, 2023

Conversation

shonfeder
Copy link
Contributor

Closes #2531

Borrows from and reverts #2534. See c59ed3d and
#2534 (comment)
for context.

This provides a workaround for #2532, by rewriting (LET f = ... IN f)(x) as
(LET f = ... IN f(x)).

  • Tests added for any new code
  • Ran make fmt-fix (or had formatting run automatically on all files edited)
  • Documentation added for any new functionality
  • Entries added to ./unreleased/ for any new functionality

Shon Feder added 4 commits April 14, 2023 16:09
Following #2534, but putting it where it'll help with quint conversion.
Now being delegated to the builder.
This reverts commit 9d5a00a.

This can't be useful as is, because any input will choke on the type
checker before we ever get to the preprocessing logic. The previous
commits move the core logic into the builder, where it fixes the problem
hit during conversion.
@codecov-commenter
Copy link

codecov-commenter commented Apr 14, 2023

Codecov Report

Merging #2536 (1e3315f) into main (327ae73) will decrease coverage by 0.05%.
The diff coverage is 92.85%.

❗ Current head 1e3315f differs from pull request most recent head be90d8b. Consider uploading reports for the commit be90d8b to get more accurate results

@@            Coverage Diff             @@
##             main    #2536      +/-   ##
==========================================
- Coverage   78.54%   78.50%   -0.05%     
==========================================
  Files         442      441       -1     
  Lines       15560    15535      -25     
  Branches     2518     2507      -11     
==========================================
- Hits        12221    12195      -26     
- Misses       3339     3340       +1     
Impacted Files Coverage Δ
...orsyte/apalache/tla/passes/pp/PreproPassImpl.scala 100.00% <ø> (ø)
...ain/scala/at/forsyte/apalache/io/quint/Quint.scala 88.00% <90.00%> (-0.39%) ⬇️
...alache/tla/typecomp/unsafe/UnsafeBaseBuilder.scala 100.00% <100.00%> (ø)

... and 4 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

shonfeder pushed a commit to informalsystems/quint that referenced this pull request Apr 14, 2023
This will be passing once
informalsystems/apalache#2536 is merged.
Comment on lines +25 to +35
def appOp(Op: TlaEx, args: TlaEx*): TlaEx = {
Op match {
// This is a workaround for the fact that that we currently de-lambda,
// because lambdas are not supported in the Apalache IR. See
// https://github.com/informalsystems/apalache/issues/2532
case LetInEx(nameEx @ NameEx(operName), decl) if operName == decl.name =>
val appliedByName = buildBySignatureLookup(TlaOper.apply, nameEx +: args: _*)
LetInEx(appliedByName, decl)(appliedByName.typeTag)
case _ => buildBySignatureLookup(TlaOper.apply, Op +: args: _*)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I like us pushing computations, which have nothing to do with building expression trees, but rather compensate for a particular deficiency in our rewriting process, into the Builder itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the review and discussion!

To note the upshot of our convo:

  • We identified that, in principle, to hold to the logic of TLA, we should not allow returning operator. So, in principle, the LET/IN form used to encode lambdas shouldn't even be allowed.
  • However, we have inherited a situation in which this otherwise illegal form is used internally to represent lambdas.
  • Since we should be able to apply lambdas, it makes sense given our current imperfect state to support this construction in the builder.
  • The key caveat is that this should be removed (and replaced with a validation check) once we introduce lambdas via Support LAMBDA in the Apalache IR #2532.

Copy link
Contributor

@Kukovec Kukovec left a comment

Choose a reason for hiding this comment

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

We discussed this in a call.

@shonfeder shonfeder merged commit 2cec6c7 into main Apr 17, 2023
shonfeder pushed a commit to informalsystems/quint that referenced this pull request Apr 17, 2023
This will be passing once
informalsystems/apalache#2536 is merged.
shonfeder pushed a commit to informalsystems/quint that referenced this pull request Apr 17, 2023
This will be passing once
informalsystems/apalache#2536 is merged.
@Kukovec Kukovec deleted the 2531/setBy branch April 20, 2023 14:14
@Kukovec Kukovec restored the 2531/setBy branch April 20, 2023 14:15
@shonfeder shonfeder deleted the 2531/setBy branch July 24, 2023 13:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Conversion of quint Map.setBy produces invalid Apalache IR
3 participants