-
Notifications
You must be signed in to change notification settings - Fork 1
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
Evaluate arbitrary lambdas in animation primitive #1169
Draft
georgefst
wants to merge
3
commits into
main
Choose a base branch
from
animations-all-lambdas
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
Merged
c7e473f
to
dfcd685
Compare
efccb9f
to
7c37be1
Compare
dfcd685
to
ab8ea0c
Compare
7c37be1
to
e99d564
Compare
ab8ea0c
to
5635552
Compare
e99d564
to
6f618bd
Compare
5635552
to
0360f3f
Compare
6f618bd
to
36076d4
Compare
0360f3f
to
24d070b
Compare
36076d4
to
d1a4f0f
Compare
Open
24d070b
to
5d52e9c
Compare
d1a4f0f
to
8571b55
Compare
7f164c1
to
85d1f94
Compare
8571b55
to
a930c2d
Compare
9a258af
to
66c14ec
Compare
Signed-off-by: George Thomas <georgefsthomas@gmail.com>
Previously, it was possible for example to take an expression `match (? : Maybe Animation) with {Nothing -> ? ; Just x -> ?}`, then, by raising `Animation`, create `match (? : Animation) with {Nothing -> ? ; Just -> ? ; _ -> ?}`. Now we ensure that those first two nonsensical branches are removed. Signed-off-by: George Thomas <georgefsthomas@gmail.com>
Signed-off-by: George Thomas <georgefsthomas@gmail.com>
a930c2d
to
a9c21a7
Compare
ce07999
to
3897c97
Compare
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.
The major limitation of #1164 is that we can only use trivial functions as the second argument to
animate
, without the evaluator getting stuck. That is, functions where only a substitution is needed for the function body to reach a normal form.Consider an expression
animate 5 (λt. circle (t × 2))
. Note that both arguments are normal forms. The problem is that evaluating this requires evaluatingcircle (0 × 2)
,circle (0.1 × 2)
,circle (0.2 × 2)
etc. in order to generate the frames of the animation. Whereas for all of our other primitives, once the arguments are in normal form, computing the normal form of the applied function is trivial. This all happens in the functionprimFunDef
, which establishes the semantics of our primitive functions, and is not set up to be able evaluate further. Even at a higher level, it's not clear how we should handle this, given that the new expressions requiring evaluation are not guaranteed to be normalizing.This PR lifts the trivial-functions restriction in most circumstances, in a hacky unprincipled way. It breaks all sorts of abstractions, and doesn't guarantee that evaluation respects the configured termination bound. Of course, it should not be merged in anything resembling its current form, but it's useful for exploring more complex animations. A proper solution will require some sort of reworking of the evaluator, and I'm not yet sure what that should look like. Alternatively, and this is my personal preference, we could just embrace the projections-based approach discussed in #1173.