Consider a complex nested function call like
(foo (bar (baz x)) (quux y))
This is a tree of function calls. The outer call to foo
has two arguments, the result of the inner call to bar
and the result of the inner call to quux. The inner
calls may themselves have nested calls.
One job of the compiler is to linearize this call tree into a sequential series of calls. So the compiler would generate some temporaries to hold the results of the inner calls, make each inner call in turn, and then make the outer call.
temp1 = baz(x) temp2 = bar(temp1) temp3 = quux(y) return foo (temp2, temp3)
Another job of the compiler is to arrange for each call to follow the calling conventions that define where the arguments are placed and where the results are returned. There may be additional tasks done at function call boundaries, for example, the system might insert interrupt checks after each call. These checks are abstracted away at the source code level. The compiler takes care of them automatically.
Sometimes, however, you want to want modify the calling conventions. For example, you might want to write in continuation passing style. Each CPS function will take an additional argument which is the continuation. The compiler won't know about this convention, so it will be incumbent on the programmer to write the code in a particular way.
If possible, a macro can help with this. The macro will ensure that the modified calling convention is followed. This will be less error prone than expecting the programmer to remember to write the code in a particular way.
The Go language has two glaring omissions in the standard calling conventions: no dynamic (thread local) variables and no error handling. Users are expected to impose their own calling conventions of passing an additional context argument between functions and returning error objects upon failures. The programmer is expected to write code at the call site to check the error object and handle the failure.
This is such a common pattern of usage that we can consider it to be the de facto calling convention of the language. Unfortunately, the compiler is unaware of this convention. It is up to the programmer to explicitly write code to assign the possible error object and check its value.
This calling convention breaks nested function calls. The user has to explicitly linearize the calls.
temp1, err1 := baz(ctx, x)
if err1 != nil {
return nil, err1
}
temp2, err2 := bar(ctx, temp1)
if err2 != nil {
return nil, err2
}
temp3, err3 := quux(ctx, y)
if err2 != nil {
return nil, err2
}
result, err4 := foo(ctx, temp2, temp3)
if err4 != nil {
return nil, err4
}
return result, nil
Golang completely drops the ball here. The convention of returning an error object and checking it is ubiquitous in the language, but there is no support for it in the compiler. The user ends up doing what is normally considered the compiler's job of linearizing nested calls and checking for errors. Of course users are less disciplined than the compiler, so unconventional call sequences and forgetting to handle errors are common.
