----- Original Message ----- From: "Igor Stasenko" siguctua@gmail.com
Hmm.. i think, you given a bad example. It depends on 'knowledge' that #ifTrue: is optimized by compiler as an execution branch, but not a regular message send.
My example was specifically what to do when we have ifTrue: optimized. But you are right to consider the general case first.
For general case we should consider passing a block as a argument, like:
bar someMethod: [^1].
But this again, not includes cases, when blocks are assigned to temps/ivars within context and never passed as arguments to message(s).
But we do know that these blocks are actually created in the home context (unlike the optimizing example I gave-no blocks are created). So if it were possible to mark the block context, that it includes an explicit return, then those are the blocks that should cause synchronization with promises. We could know that a block has a return at compile time, so we would just need to have a new block creation bytecode that marked the block: #bytecodePrimBlockCopyWithReturn.
I thought a bit about marking a method context containing blocks with non-local returns with special flag, which will force context to not activate until all free variables in method are resolved (agruments/temps). This means that before any activation (entering method and each send in method it will wait for resolving all promises it contains). But i'm still doubt if this gives us anything.
Where does a block return from if it has an explicit return? The home context or the calling context? I think it is the calling context.
So what you just said about marking a method context if it contains blocks with non-local returns. How do you know the block has a non-local return? As I mentioned, we could mark the blocks. We could mark the methods that CREATE blocks that return. At runtime, we could look at the method flag for non-local return and look at all args and temps for blocks with the flag and synchronize. I agree with you that it will have to be before every send.
There is many methods which operate with blocks by sending #value.. to them. And these methods actually don't care if those blocks contain non-local returns or not. They simply do their job.
What do you mean here?
Cheers, Rob