Conversation
emilypi
left a comment
There was a problem hiding this comment.
I'd like to see a regression that addresses nested defpacts in here.
8d22edf to
bfd3f1c
Compare
This PR concentrates solely on ensuring that each step's result type is consistent with the overall defpact type. While Stuart's nested defpact example remains a separate challenge, it is regarded as an independent issue and will be addressed in a future PR. This current update is dedicated to aligning step result types with the defpact's defined type. |
| (defpact test-pact-guards (id:string) | ||
| (step (step1 id)) | ||
| (step (step2 (read-msg "id")))) | ||
| (step (let ((s2 (step2 (read-msg "id")))) "step2"))) |
There was a problem hiding this comment.
What does this binding do, and how is it extending the test? Is this suggesting that the return type of test-pact-guards should be :string?
There was a problem hiding this comment.
step has return type string, with this change, we enforce that all steps have the same return type. Hence, the change will return the "step2" string. This is a fix to a pre-existing test (on caps).
There was a problem hiding this comment.
Could you please add some comments to the test describing what's going on here and what exactly is being tested by these odd constructions? (Namely, binding to a name that is never used). Everything else looks good!
This PR enhances the typechecking for defpacts by ensuring consistency in return types across all steps. Previously, varying return types were permissible for each step. This update mandates that the return type for all steps aligns with the defpact's defined result type.
PR checklist:
cabal run tests. If they pass locally, docs are generated.pact -t), make sure pact-lsp is in sync.Additionally, please justify why you should or should not do the following: