And last thing there's an absolutely cheap way to remove optimization: don't provide a block argument. For example provide a message send instead:
[true or: [false] yourself] bench.
'39,900,000 per second. 25 nanoseconds per run.'
[true or: [false]] bench.
'177,000,000 per second. 5.63 nanoseconds per run.'
If you like syntactic sugar, implement BlockClosure>>unoptimized as ^self and write:
true or: [false] unoptimized.
And last, here is a draft that I wrote in 2015 in the pharo thread about mustBeBoolean workaround
...snip...
> That's
the way to go. I think some people like Camille are already working on
it. Basically, you need abstraction over what is happening which is
implemented in the image instead of the VM for simplicity and
maintenance, and what the programmer wants to see which is relevant for
him.
> For optimized selectors, one could mark
the methods with pragmas as 'Do not show in debugger' and in addition
rewire the bytecode to source code mapping from the method compiled
on-the-fly executed in ExecuteUnoptimizedIn: to the regular method.
> But
as I stated for Slots, it is more complicated. The debugger cannot
detect if the stack is currently in a slot access, as it has access only
to the bottom 20 frames. Having the debugger access the full stack is a
bad idea as it would slow it considerably, making the debugger unusable
on devices such as the raspberry pie, and hard to use to debug
recursive code. Maybe a solution could be that if the compiled bytecode
for a slot has an interrupt point (branch, back jump, send), then it
could change a state in the process, probably encoded in the process
instance variables, and as the debugger has access to the process it is
showing it would know.
It sounds like inserting an elephant in the stack and keep prretending it's turtle all the way down ;)
Isn't the cheat too visible?
Some essential Smalltalk principles/properties shall better not be lost:
- there's a well defined virtual machine which acts as boundary
between Smalltalk code and non Smalltalk (primitive) code.
- everyone should be in a position to understand
every single bit of Smalltalk code and the debugger is the ultimate
introspective tool to do so.
There are times when you want to debug slot implementation itself, think of it...
And
there will be times when you want to introspect how the machinery
works, maybe because you want to understand time spent in a method or
come with a similar trick.
I hope it does not imply debugging at bytecode level, this would be a great loss.
To me, the whole #or: story sounds like you came with a complex workaround for hiding an optimization.
And now you're trying to hide the workaround with an even more complex machinery which endanger first principles:
Just admitting and learning that there are a very few exceptions to the rules sounds very cheap in regard.
I wish you success, but it's scary!