-
Notifications
You must be signed in to change notification settings - Fork 10
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
Uncurry Pipeline Usage #106
Comments
Does #107 address this? |
Can this be closed as fixed by #115 ? |
Not yet -- Artem is still working on more required indexing changes. |
Made improvements in #127. That is, now given a term whose type is an n-iterated fun-type with codomain However, that does not suffice for general cases. E.g. compiling |
Note that #138 changes the compilation to optimize costly uncurry with a simple replacement strategy. |
Now that we tested out
uncurry
so that our compilation can be intuitively tested pointwise both in Geb and in Poly instead of passing through the additional isomorphisms, we have a question regarding how to actually implement it.uncurry
currently needs three arguments, two for domain and codomain of the exponential object and one for the morphism we are applying it two. The domain/codomain are needed since we don't have accessors toso-hom-obj
.In order to not burden the user with providing explicit types, we will have to figure out (at least initially until higher-order function translation to Vamp-IR is implemented) how to streamline this process.
The text was updated successfully, but these errors were encountered: