-
Notifications
You must be signed in to change notification settings - Fork 37
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
add inlining pragma #254
add inlining pragma #254
Conversation
Noticed it can loop on some examples, need to fix it. Hm, seems to be caused by the fact that the record-pattern translation cannot happen if we match on one of the (erased) fields, even though inlining the Haskell code is morally fine. So we cannot use Agda's reduce machinery to do the inlining for us. Gonna roll my own. |
@flupe what's the status on this? |
Getting back to this now. |
Somehow #247 adding So the PR is ready. Instead of defining our own routine for inlining, we currently rely on Agda's It should be fine to allow pattern-matching on erased arguments (say, an equally type), but |
Thanks! |
Unboxed records lead to the definition of many functions (on the Agda side) that lift functionality to unboxed records by wrapping and unwrapping accordingly. However, once compiled this overhead disappears and the resulting output could be inlined.
This PR introduces the
{-# COMPILE AGDA2HS name inline #-}
pragma that tells agda2hs to do the inlining automatically. Underapplied inline functions will be eta-expanded so that the substitution still happens.compiles to:
Right now the names of the inserted lambdas come from the names given to the patterns in the inlined function. I suspect these could shadow names outside of where the inlined function is being used. Suggestions welcomed for making it more robust.