If Paws is ever to be remotely performant, then the (many) lowest-level operations, constructed libside as Executions, need to be evaluated without every single combination causing the operation to be unstaged, and then cause it to sit through the reactor queue again.
Clearly, it's desirable that a truly basic series of operations on objects without overriden receivers be processable by optimised implementations during a single reactor-tick …
… but that raises a huge question: how can we allow such a series of operations to safely jump the reactor queue? The queue maintains order-of-operations; and if any operation is allowed to jump that queue in any situation, that operation could theoretically be out of order. (Not to mention fucking up mutability-safety by skipping the responsibility checks, eh?)
So: this needs thinking-through, to figure out if it's actually dangerous; and then, hopefully, munging-up of the design until we can safely do this. (I'm willing to make some small concessions at the design level for this, despite compramising on the design for the sake of performance being generally against my principles, because this is clearly one of the biggest bottlenecks in the entire design. Could easily find one extremely common ‘operation’ taking ten, or even fifty, ticks, instead of one or five. Ick.)
If Paws is ever to be remotely performant, then the (many) lowest-level operations, constructed libside as Executions, need to be evaluated without every single combination causing the operation to be unstaged, and then cause it to sit through the reactor queue again.
Clearly, it's desirable that a truly basic series of operations on objects without overriden
receivers be processable by optimised implementations during a single reactor-tick …… but that raises a huge question: how can we allow such a series of operations to safely jump the reactor queue? The queue maintains order-of-operations; and if any operation is allowed to jump that queue in any situation, that operation could theoretically be out of order. (Not to mention fucking up mutability-safety by skipping the responsibility checks, eh?)
So: this needs thinking-through, to figure out if it's actually dangerous; and then, hopefully, munging-up of the design until we can safely do this. (I'm willing to make some small concessions at the design level for this, despite compramising on the design for the sake of performance being generally against my principles, because this is clearly one of the biggest bottlenecks in the entire design. Could easily find one extremely common ‘operation’ taking ten, or even fifty, ticks, instead of one or five. Ick.)