ssm-lang / sslang

A language built atop the Sparse Synchronous Model
BSD 3-Clause "New" or "Revised" License
18 stars 0 forks source link

Support codegen for closure bindings #87

Closed j-hui closed 2 years ago

j-hui commented 2 years ago

This PR adds support for the new closure bindings supported by our runtime library.

A few expected changes:

And two changes perhaps warrant some discussion:

  1. (!!) Generate static closure for each global function, so that we don't have to allocate a dynamic closure for each such reference.

    I chose to do this because the alternatives are more complicated; dynamically allocating closures for top-level functions requires us to start tracking their lifetimes, which we don't yet have the capability for, while directly inlining call to the enter function begins to encroach upon optimization, which I don't want to tackle yet (and shouldn't do in codegen anyway).

  2. (!!) In the codegen phase, side-effectful expressions (other than function calls) are now forbidden as par operands.

    I realized while working on this PR that our old compilation scheme was wrong. Say e1, e2, and e3 are all side-effectful functions; given par { e1 () | e2 (e3 ()) }, one would expect the effects of e1 to take place before e2 and e3. However, the old compilation scheme would first evaluate e3 () to produce the argument for e2, before yielding to e1 and e2, meaning we would observe e3's effects first.

    Such parallel effects should be abstracted out in an earlier compiler phase, so that the order of effects obey what we would expect of par expressions. So in codegen, I require that all operand expressions of a par expression be pure and "simple".

I'm open to suggestions for how to better address two of these issues, especially 1, though my current plan is to just push on ahead and refactor later if we find that either of these choices lead to issues.

j-hui commented 2 years ago

wtf why did it fail earlier

i swear i tested this locally

j-hui commented 2 years ago

also why was the build cache invalidated

i have questions.

j-hui commented 2 years ago

Still no clue why the build is taking so damn long but at least tests are passing now.

I wrote one test, closures.ssl, that is essentially the same as the example I wrote in ssm-runtime. I'll probably write a couple more tests, i.e., I want to get map working. I'm also going to attempt some lambdas and see if @hmontero1205 's closure conversion works as advertised (!!).

j-hui commented 2 years ago

Thanks for the review @EmilySillars !

does SSLANG support pattern matching on closures/is pattern matching for closures supported in this PR?

no, that's not possible (in general, one cannot pattern-match on any function type).

I think the way closure tag fields are constructed and the way pattern matching works currently will cause problems for representing fully applied ADTs as closures down the line. This is an issue for the future though.

In your example, the closure will be evaluated (i.e., reduced) to a value of value of type Shape before being scrutinized. So that should be ok.