Home/

...

/

Challenges for Improving Imperative Probabilistic Workflows

Challenges for Improving Imperative Probabilistic Workflows

In the previous lesson, we gave you several challenges for improving our DSL for imperative probabilistic workflows.

Compiler Writer’s Approach

Let’s solve a few puzzles:

Question One: You are walking down the street when you see a can of gasoline, some matches, a house on fire, a wrench, a fire hose, and a fire hydrant. You consider the house being on fire to be problematic, so what do you do?

Question Two: You are walking down the street when you see a can of gasoline, some matches, a house not on fire, a wrench, a fire hose, and a fire hydrant. What do you do?

That’s how compiler writers approach problems. We know how to do lowerings in a very simplified version of probabilistic C#; to lower more complicated forms, we keep on applying the “lower it to a previously solved problem” technique:

  • goto is straightforward: you evaluate the “statement method” that is the statement you’re going to.

  • Once you have goto and if, it is straightforward to implement do, while, break and continue; reduce those to combinations of if and goto, which are previously solved problems.

  • for loops are just an irritatingly complicated version of while, which is an already solved problem.

  • Implementing throw and try is tricky because it is a non-local goto. Throughout the history of C#, methods involving various combinations of try, catch, finally, throw, yield return, yield break and await had restrictions placed on them in C# because of the complexities involved in handling non-local branching in complex workflows. The details of how a compiler team might go about dealing with the combination of throw and sample in a probabilistic workflow are beyond the scope of this course; if this subject interests you, consider doing research on how the C# compiler implements asynchronous workflows that can throw.

  • We have not solved the problem for try, which means that we’re blocked on foreach, lock and using, all of which are syntactic sugars for try.

To allow the sample operator in more places, again, reduce the problem to previously solved problems. For example:

 ...