Bamboo is my answer for designing a reasonable programming language for Ethereum contracts. By reasonable I mean easy to reason about. Especially I chose to make it explicit what can be called when.

In all existing programming languages for Ethereum, any interface can be called at any time by default. Additional checks would prevent untimely calls to wrong interfaces, but the outermost structure does not show when to call what.

contract CrowdFund {

function toBeCalledDuringFunding() {

// perhaps check it's during funding

}

function toBeCalledAfterFailure() {

// perhaps check it's after failure

}

function toBeCalledAfterSuccess() {

// perhaps check it's after success

}

function notSureWhatThisDoes() {

// This can mess with all other code.

}

}

In Bamboo, the outermost structure shows the modes of operation.

contract Funding() {

function toBeCalledDuringFunding() {

// something something

return true then Funding();

}

function endFunding() {

if (something)

return (true) then FundingSuccess();

else

return (false) then FundingFailure();

}

}

contract FundingSuccess() {

function toBeCalledAfterSuccess() {

// something

}

}

contract FundingFailure() {

function toBeCalledAfterFailure() {

// something

}

}

Now you see three contracts, but they are not deployed separately. One becomes another. See the line return (true) then FundingSuccess(). This makes the contract become a FundingSuccess() contract. Only after that, toBeCalledAfterSuccess() function is accessible.

This looks a bit like a state machine, and actually it is. The language forces the state-machine approach to programmers. Every time the control flow is lost, the programmer needs to say “then” and specify the left state. Even when the contract calls something, since that something might call back, a state needs to be specified.