Hmm, if almost everything desugars to function/method calls, and we have a generic .wrap mechanism in addition to the MMD mechanism, then the only remaining technical question is whether you can actually name the function or method (or set of multimethods) to which the surface code is being desugared. Layered over that question is the cultural issue of whether the underlying function is blessed into an official API. (Which, if you squint, is just the same question writ large: "Does this thing have a Name?").
I think we've pretty much solved the naming of sets of multimethods by allowing types in the reference-taking syntax, but we do probably have to think through whether that just calculates a set of multies when you take the reference, or lazily just remembers the types so that it can see new multis added after the reference is taken. The optimizer would probably prefer the former, while semantic transparency would probably argue for the latter. Basically, can we .wrap a multi that doesn't entirely exist yet? The default answer should probably be yes, with the option to tell the optimizer otherwise. Not sure if that should just be a pragma or something you put on the actual reference taking syntax... And if the latter, which syntax? Larry
