Currently our stacks have a maximum size, and the memory for each is allocated at execution start. However this limits our programs, and will eventually cause our programs to revert, which is against the overall philosophy of doing no-ops on invalid states. We have to look into ways of letting our stacks grow, either in memory with some sort of allocator, or simply by using transient storage. Implementation simplicity as well as gas cost should be considered.
Currently our stacks have a maximum size, and the memory for each is allocated at execution start. However this limits our programs, and will eventually cause our programs to revert, which is against the overall philosophy of doing no-ops on invalid states. We have to look into ways of letting our stacks grow, either in memory with some sort of allocator, or simply by using transient storage. Implementation simplicity as well as gas cost should be considered.
when stacks grow certain operations increase in gas cost (yank and shove need loop), so in general there should be fixed limits to allows us to evade tx gas limit. the docs have this for the code stack:
MAX-POINTS-IN-PROGRAM: This is the maximum size of an item on the CODE stack, expressed as a number of points. A point is an instruction, a literal, or a pair of parentheses. Any instruction that would cause this limit to be exceeded should instead act as a NOOP, leaving all stacks in the states that they were in before the execution of the instruction.
could this be applied to all other stacks?
to disincentivise stack overflow the NOOP could be accompanied by an fitness penalty somehow.
our brains instinctively know their stack size, how?
when I fail to understand something, I know it, there is null on the stack, as before.
when stacks grow certain operations increase in gas cost (yank and shove need loop), so in general there should be fixed limits to allows us to evade tx gas limit. the docs have this for the code stack:
```
MAX-POINTS-IN-PROGRAM: This is the maximum size of an item on the CODE stack, expressed as a number of points. A point is an instruction, a literal, or a pair of parentheses. Any instruction that would cause this limit to be exceeded should instead act as a NOOP, leaving all stacks in the states that they were in before the execution of the instruction.
```
could this be applied to all other stacks?
to disincentivise stack overflow the NOOP could be accompanied by an fitness penalty somehow.
our brains instinctively know their stack size, how?
when I fail to understand something, I know it, there is null on the stack, as before.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Currently our stacks have a maximum size, and the memory for each is allocated at execution start. However this limits our programs, and will eventually cause our programs to revert, which is against the overall philosophy of doing no-ops on invalid states. We have to look into ways of letting our stacks grow, either in memory with some sort of allocator, or simply by using transient storage. Implementation simplicity as well as gas cost should be considered.
when stacks grow certain operations increase in gas cost (yank and shove need loop), so in general there should be fixed limits to allows us to evade tx gas limit. the docs have this for the code stack:
could this be applied to all other stacks?
to disincentivise stack overflow the NOOP could be accompanied by an fitness penalty somehow.
our brains instinctively know their stack size, how?
when I fail to understand something, I know it, there is null on the stack, as before.