Feature request: mechanism for removing variables from the stack

[tinybike]

I'd like to propose adding a mechanism to Solidity that allows removing variables from the stack. I'm not familiar with Solidity's internals, so I do not have an opinion about how to implement this feature. However, I assume it is possible to implement because Serpent had this feature. For reference, Serpent's with keyword was used for this:

# nothing on the stack
with x = 1:
    # x is on the stack
# nothing on the stack

Motivation: Augur recently completed its migration to Solidity from Serpent. One pain point for us was that Solidity lacks a way of removing variables from the stack. Because of this, the stack depth limit drove a number of architectural decisions (about e.g. how/whether to split up functions) that we would have preferred to make independently of language-level constraints.

(This is related to #2693, but I thought it was worthwhile to make a separate issue for manual stack management.)

[federicobond]

@tinybike can you point me to an example of a contract that had to deal with this constraint?

[tinybike]

Sure, one contract that required quite a bit of refactoring due to this constraint was https://github.com/AugurProject/augur-core/blob/master/source/contracts/trading/FillOrder.sol. Our market creation functions are another good example.

[federicobond]

Thanks, those contracts are more complex than the average Solidity contract I have seen in the wild, and I see why the standard solution of splitting your functions may be inconvenient.

There have been some proposals to change variable scoping. This is a good argument in favor of introducing block scoping. It lets us do this, like in C/C++:

function foo() {
   uint a = 3;
   {
      uint b = 5;
      doSomething(b);
   }
   // b is no longer in scope
}

[chriseth]

@tinybike you can move variables from the stack into memory by packing them into structs. Did you consider this when refactoring the function? Do you still have the old version of the file for comparison?

[tinybike]

@chriseth Yes, we ended up packing our variables into structs -- the FilledOrder and Participant structs on the FillOrder.sol contract linked above are examples of this. Packing into structs (and splitting apart functions) allowed us to get things up and running, so this definitely isn't a show-stopper. It just feels a bit "icky" to me to have a strong language-level coupling between a variable's type and where it is stored, if that makes sense.

The old version was in Serpent. In the old version, takeAskOrder and takeBidOrder were in separate files, but the basic code paths were the same: https://github.com/AugurProject/augur-core/blob/684c8065e723fe7003b1bb2fbfb7516656ddc447/src/trading/takeAskOrder.se https://github.com/AugurProject/augur-core/blob/684c8065e723fe7003b1bb2fbfb7516656ddc447/src/trading/takeBidOrder.se

[axic]

This is now supported by having C++ scoping.