Not-so-shameless (but useless) plug here - I re-designed a portion of Cassette using IRTools so that I could understand the Cassette transform better - I put together a pedagogical package which illustrates this: https://github.com/femtomc/Mixtape.jl
If you’re curious about compiler metaprogramming, these ~40 lines of code might prove enlightening 
I really excited about all these plans! And I’d be very happy to join the meetings.
So maybe we need “my waking hours in UTC” for each of us, or something like that?
For me in central Europe (UTC+2 during DST, otherwise +1) that would be about 06:00–18:00 UTC currently.
I agree it would be great to have a general-purpose abstract type for tracing. @alex-lew helped me connect Soss to the trace type needed for Gen, but I have no idea how this relates to Turing’s representation. It would be good to get a better understanding of the
VarInfostuff and see if there’s a best-of-both-worlds, or if some tradeoffs are unavoidable.
VarInfo is really just one big float vector with a couple of extra arrays to remember where each variable went. The additional difficulty is that we have this VarName type, representing any indexed variable, like @varname(T[1][:]) – basically just a Symbol and a tuple of tuples. Currently indexing with that into VarInfo is difficult sometimes (same in AbstractMCMC chains), because information about the “original shape” is not completely preserved. (@mohamed82008, correct me if I have a flaw in my mental model.)
I have lately been thinking about something like Gen’s trace mixed with Turing’s idea: an underlying array of type T, of which you can take reshaped views, and on top of it some kind of trie or R-tree structure to allow proper indexing and slicing with VarName. This would be an AbstractDict{VarName, T} with fully general indexing, but still one array. And a kind of “write-once” data structure, due to the nature of how RVs work. But I stopped trying at some point.
My big question here is, is there an opportunity for an IR between the model syntax (as input by the user) and this lower-level representation?
Another point I have had some ideas about 
I believe there must exist some some possibility to extend existing SSA-based Julia IR with “sampling statements”/tildes (“single static sampling form”?), and maybe some CPS stuff, so that there’s a low level representation of every probabilistic program very similar to the IR of the corresponding Julia program, which is additionally in direct correspondence with a monadic formulation (for each basic block, at least). The difficult part is “temporary RVs” like sampling a scalar and putting it into an array. Maybe some approaches from linear type systems can help with that. But that’s still to be worked out.
@cscherrer should we start putting together some dates for a call? It’s the end of the month now. Should we aim for a call meeting in the middle of the next month (i.e. a few weeks from now)?
Thanks for following up on this @McCoy. Not sure what the best way is to go about this. I guess the biggest blocker would be conference deadlines, right? Anything coming up to account for?
Yeah, I’m totally out of the loop on that. I think the answer is that there are a few - but I’m not sure.
Let me start banging on doors on Slack and report what I find.