Skip to content
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

Merged
merged 21 commits into from
Sep 4, 2024
Merged

Properly scoped iteration ops for IL #119

merged 21 commits into from
Sep 4, 2024

Conversation

rossberg
Copy link
Collaborator

@rossberg rossberg commented Aug 3, 2024

This PR generalises IL iteration expressions to proper parallel maps, as proposed in the meeting the other day. That is, the IL expression form

e*{x1, ... ,xN}

becomes

e*{x1<-e1, ... ,xN<-eN}

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.

  • Unlike the previous form, this is closed under substitution, and hence allows reduction.
  • The notion of variable dimensions is no longer needed in the IL, ordinary list and option types suffice.

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

def $f(x*, y*) = (x + y)*

elaborates to IL

def $f(xs, ys) = (x + y)*{x<-xs, y<-ys}

(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?)

@rossberg rossberg changed the title Iterscope Properly scoped iteration ops for IL Aug 3, 2024
@f52985
Copy link
Collaborator

f52985 commented Sep 4, 2024

Now the algorithmic backends support the new IterE.

It took a bit longer than I initially expected,
mainly due the the case where IterE appears as the binding target, (i.e. Let x* = ...)
which made the inference of identifier binding (a.k.a. animation) a bit tricky.
(Previously, we ignored all of the "iters" when infering the identifier binding,
so all of x = ..., x* = ..., x** = ..., were all simply treated as the "binding to the variable named x".
But now, we have to keep track of what are the actual variables that are bound by this equation,
i.e., "binding to the variable named x, x*, and x**" respectively.)

Now it's all resolved anyway, and all the tests are passing again!

(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?)

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.

@rossberg
Copy link
Collaborator Author

rossberg commented Sep 4, 2024

Cool, thank you very much! I'll land this then.

@rossberg rossberg merged commit 44144bd into main Sep 4, 2024
8 checks passed
@rossberg rossberg deleted the iterscope branch September 4, 2024 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants