A few simplifications to the semantics#4
Draft
OwenConoly wants to merge 12 commits intoChezJrk:mainfrom
Draft
Conversation
Contributor
Author
25009d7 to
389314e
Compare
Contributor
Author
|
Unlike other changes here, 9f3c0ad actually changes the semantics in a non-meaning-preserving way. I think the old meaning was buggy (i.e., out of sync with semantics of shallowly embedded programs). In contrast, it seems quite subjective whether 389314e is a good idea. My subjective opinion is that it makes things prettier, and my objective-ish observation is that it makes things easier. |
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.
I noticed that the type-context parameter to
eval_expris redundant (all the information in it should be contained in the evaluation context, anyway), so I removed it.Is it okay to do this? Obviously the type-context parameter wasn't important for current functionality, but is it important for some yet-to-be-implemented functionality? Or was the type context there for aesthetic reasons?
For context, I am currently trying to prove the correctness of a transformation from PHOAS ATLexprs to regular ATLexprs. Doing this requires juggling some contexts. Contexts (like balls) are easier to juggle when there are fewer of them, so I felt motivated to get rid of the type-context parameter.
(This is on top of the changes in #3, which is why Github reports a big diff for this PR. In reality, the only extra change is b2436b1, which only changes about 400 lines.)