multi-holes do not evaluate

[cyrus-]

[disconcision]

@cyrus- A solution to this would involve firming up some decisions about the semantics of incomplete programs. First issue is that multiholes in the current implementation reflect two different kinds of error (technically three but i'm going to ignore backpack issues that will not be present in the new tylr). Singleton multiholes represent sort errors, whereas 2+ multiholes represent missing infix operations. This second case is impacted by sort issues though, as there are infix operator (currently only ann/ascr) which take different-sorted children.

It's likely a reasonable default to say, for multiholes in expressions at least, to treat the contents as expressions (if it is possible to parse them as expressions), and assign them the semantics of either tuples or semicolons or reverse semicolons as per the slack discussion, with the former being the conservative option. However, this might require some coordination with the syntax side, which currently uses some slightly ad-hoc logic for multihole component sort assignment.