[Cuis-dev] unnecessary punctuation

[Andres Valloud]

Yeah, same reason why or: / and: are faster than | and &.

On 6/12/24 3:32 PM, Jaromir Matas via Cuis-dev wrote:
> 
> 
> 
> On 12-Jun-24 11:32:59 PM, "Mark Volkmann via Cuis-dev" 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> 
>> On Wed, Jun 12, 2024 at 4:28 PM Vanessa Freudenberg 
>> <vanessa at codefrau.net <mailto:vanessa at codefrau.net>> wrote:
>>
>>     On Wed, Jun 12, 2024 at 6:56 AM Mark Volkmann via Cuis-dev
>>     <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>>
>>         I saw this example in a YouTube video about Smalltalk this
>>         morning:
>>
>>         (2 > 3) ifTrue: ['Yes'] ifFalse: ['No']
>>
>>         It seems to me that none of the parentheses or square brackets
>>         are needed here.
>>         The following works the same for me.
>>
>>         2 > 3 ifTrue: 'Yes' ifFalse: 'No'
>>
>>         Is it true that keyword messages that take no-arg blocks can
>>         always take a literal value instead?
>>         It seems this works because the `Object` class defines the
>>         `value` method to just return `self`.
>>
>>
>>     Yes it only works because of Object>>value.
>>
>>
>> I assumed that was intentional to support using objects that are not 
>> blocks in cases like this.
>>
>>     It's also twice as slow to leave out the block brackets because it
>>     prevents compiler optimizations and forces actual sends to be
>>     made. You can verify that by benchmarking, and understand it by
>>     looking at the bytecodes generated and running a message tally.
>>
>>
>> I believe you, but I'm curious why it's faster to send the `value:` 
>> message to a block than to some other kind of object. Are you saying 
>> that the optimizations make it so the `value:` message is not actually 
>> sent to a block in this case and code in the block gets inlined?
>>
>  >> It's also twice as slow to leave out the block bracket [...]
> 
> Interesting - I've never realized the difference :) So if I understand 
> correctly the #ifTrue:ifFalse message gets inlined only when used with 
> block arguments, and it gets really sent when used without blocks; which 
> means not only there's one more send but also that **both** 'Yes' and 
> 'No' expressions get evaluated before sending #ifTrue:ifFalse (hence 
> twice as slow?). Inlining allows the runtime to evaluate only the 
> "right" alternative. Here's the bytecode:
> 
> 2 > 3 ifTrue: 'Yes' ifFalse: 'No'
> 
> 49 pushConstant: 2
> 51 pushConstant: 3
> 53 send: >
> 54 pushConstant: 'Yes'
> 55 pushConstant: 'No'
> 56 send: ifTrue:ifFalse:
> 57 returnTop
> 
> 
> (2 > 3) ifTrue: ['Yes'] ifFalse: ['No']
> 
> 49 pushConstant: 2
> 51 pushConstant: 3
> 53 send: >
> 54 jumpFalse: 57
> 55 pushConstant: 'Yes'
> 56 jumpTo: 58
> 57 pushConstant: 'No'
> 58 returnTop
> 
> Thanks,
> Jaromir
> 
> 
> 
> 
> 
> 
>>
>