-
Notifications
You must be signed in to change notification settings - Fork 9
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
Properly scoped iteration ops for IL #119
Conversation
Now the algorithmic backends support the new It took a bit longer than I initially expected, Now it's all resolved anyway, and all the tests are passing again!
Yes, that would be possible. Although the generated prose still uses a bit implicit notation to express such cases, we are in the process of figuring out the difference of the manually written prose and the generated prose and trying to minify the difference, and this PR would be indeed useful during that process. |
Cool, thank you very much! I'll land this then. |
This PR generalises IL iteration expressions to proper parallel maps, as proposed in the meeting the other day. That is, the IL expression form
becomes
where x1...xN are locally scoped variables. For each ei of type ti*, xi iterates over its elements of type ti. In other words, this simply is an n-ary
mapN (λ x1 ... xN. e) e1 ... eN
. All ei must evaluate to lists of the same length. Likewise for options.Both make for a simpler and cleaner IL semantics overall. Dimensions still exist in the EL, but are elaborated away by introducing separate variables for each nesting level. For example, EL
elaborates to IL
(In reality, xs and ys will currently be named
"x*"
and"y*"
internally.)This will require adapting the IL2AL translation, and possibly changes to the AL itself, to handle the more general form. I made some obvious minor changes to get it to compile again. But I'm not sure what the right changes are to support prose rendering in the best manner. @f52985, can I once more leave that part to you?
(I note that this form also matches more closely the manually written prose, where the equivalent is expressed as "for each xi in x* [and corresponding yi in y*] do e", etc. Perhaps this change could even simplify generating such prose?)