[Cuis-dev] unnecessary punctuation

[Jaromir Matas]

Hi,
It finally clicked; rusty brain... sorry for my confusion :)

The correct semantics of
   `cond ifTrue: a ifFalse: b `
is of course evaluate a, then b, then send ifTrue:ifFalse:.

The optimization in case
  `cond ifTrue: [something] ifFalse: [something]`
_doesn't_ change this semantics.

And in case a and b contain blocks it's also true that
   cond ifTrue: a ifFalse: b
evaluates at most one of the blocks despite this _doesn't_ get optimized 
via the bytecode jumps.

So the optimization is applied only when there are square brackets in 
ifTrue:ifFalse: (same for #and: etc). This got me confused, sorry.

An example - bytecode not optimized but indeed the code in b doesn't get 
evaluated:
Duck >> duck

     | a b |
     a := [^2]. b := [self error].
     2 < 3 ifTrue: a ifFalse: b

Many thanks,
Jaromir


On 15-Jun-24 1:33:32 AM, "Martin McClure via Cuis-dev" 
<cuis-dev at lists.cuis.st> wrote:

>On 6/14/24 05:24, Jaromir Matas via Cuis-dev wrote:
>>And back to the original Mark's question (roughly) - why would it be bad to modify the compiler so that
>>
>>`cond ifTrue: a ifFalse: b`
>>
>>is treated the same way as
>>
>>`cond ifTrue: [a] ifFalse: [b]`
>>
>>i.e. optimized using bytecode jumps rather than sending #ifTrue:ifFalse: ?
>
>This would be a major change to the semantics of Smalltalk.
>Consider that a and b are arbitrary expressions.
>
>   cond ifTrue: [a] ifFalse: [b]
>
>evaluates at most one of the expressions, while
>
>   cond ifTrue: a ifFalse: b
>
>by Smalltalk evaluation rules evaluates a, then b, then sends ifTrue:ifFalse:.
>
>Smalltalk has a very simple syntax that relates directly to simple message-sending and assignment semantics. Very easy to understand. Changing the compiler to use bytecode jumps in the latter case would badly undermine this simplicity.
>
>Regards,
>-Martin
>-- Cuis-dev mailing list
>Cuis-dev at lists.cuis.st
>https://lists.cuis.st/mailman/listinfo/cuis-dev