Open
Conversation
…to remy/pureProcedures
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
Instead of redefining how to do name resolution in each phase in the translation from Laurel to Core, define resolution once in a single phase. Currently resolution is done again after each phase. This introduced partially duplicated work but we expect to reduce that in the future using caching.
The Python through Laurel pipeline currently can not resolve each reference because it adds some prelude definitions, that are referenced by the generated code, only at the Core level instead of at the Laurel level. To still enable the Python through Laurel pipeline to work, I had to add a few hacks in the code that were less explicit before this PR. In a follow-up PR, I will create a Laurel-level prelude for Python through Laurel, so that we won't need those hacks any more.
For Laurel tests, this PR includes changes to ensure that the program resolves without errors after each phase:
typeTag: TypeTagfield of the composite datatype is only added to that datatype during the typeHierarchy phase, since that's the phase whereTypeTagis defined.const,selectandupdateare now added as part ofCoreDefinitionsForLaurel.lean, as Laurel functions with an "External" body, meaning they're ignored during the translation to Core. This way, references to them can be resolved during resolution.HeapParameterization, fields for composite type definitions are deleted, so their names don't conflict with the constructors of the generatedFielddatatypeMisc:
softPanicthat does not print the stacktrace.Testing