GitLab

Whenever I see a join point pretty-printed, I have to register a mental continuation in my mind that control-flow might eventually jump back to it. I have to skip the potentially huge join RHS and lose all the context of what executed before. Then when the join point is entered, I have to scroll back up.

Meanwhile, the connection to SSA in imperative langauges is pretty well established. There, the join point (a basic block with phi instructions) is normally printed after the basic blocks that jump to it, if the basic block schedule permits (no loop header).

Why don't we do ourselves a favor and do the same in Core and STG? Instead of something like

join {
  j x = ...
} in case ... of {
    A -> jump j 42
    B -> jump j 13
    C -> True
  }

We could print

case ... of {
  A -> jump j 42
  B -> jump j 13
  C -> True
} join-where {
  j x = ...
}

Or some such. Advantages:

• Reading the listing top-down actually represents control-flow
• Less indentation

Disadvantages:

• It's potentially confusing that the binding occurrence of j appears after its uses
• I'm not 100% sure if the syntax is unambiguous. For example, in let { f = ...; } in jump j join { j = ...;} it's not completely clear if the let or the join binds stronger...

Regarding the latter point, I'd also consider

join [j] {
case ... of {
  A -> jump j 42
  B -> jump j 13
  C -> True
} where {
  j x = ...
}

an improvement without the ambiguity.