On Tue, 13 Jun 2006 09:57:45 +0200, Andreas Raab wrote:
> Klaus D. Witzel wrote:
>> On Tue, 13 Jun 2006 01:08:19 +0200, Andreas Raab wrote:
>>> Klaus D. Witzel wrote:
>>>> On Tue, 13 Jun 2006 00:13:18 +0200, Andreas Raab wrote:
>>>>> Klaus D. Witzel wrote:
>>>>>> Ah. And I was believing the description in True>>#ifTrue:
>>>>>> -------
>>>>>> ifTrue: alternativeBlock
>>>>>>     "Answer the value of alternativeBlock. Execution does not  
>>>>>> actually
>>>>>>     reach here because the expression is compiled in-line."
>>>>>>      ^alternativeBlock value
>>>>>> -------
>>>>>>  So the bug is in the documentation? This is not an easy one: who  
>>>>>> would doubt the implementation of such an essential behavior?
>>>>>
>>>>> I don't see a bug in either the implementation nor the documentation  
>>>>> of ifTrue:/ifFalse:. You need to look at False>>ifTrue: if you want  
>>>>> to understand the described behavior of ifEmpty:
>>>>  No. I do not look into the implementation of #ifFalse: for finding  
>>>> out if the implemntaion of #ifTrue: matches its own specification ;-)  
>>>> Nobody does :-D
>>>
>>> Geesh. Try to do some reading next time before you write something.
>>  Keep cool, I just mistakenly typed #ifFalse: instead of copying your  
>> "False>>ifTrue:" no need to assume something about what other people  
>> actually *do* read, you're > 80% times wrong anyways ;-)
>
> If you meant to write "False>>ifTrue:" instead of ifFalse: your comment  
> makes no sense whatsoever to me. Seriously, your first comment about not  
> looking at the implementors of ifFalse: when looking into an ifTrue:  
> issue is at least logical (though not what I said) but with your latter  
> statement it makes no sense. Why wouldn't you look at False>>ifTrue: if  
> that is the code that is actually executed by ifEmpty:?

I'm sorry that my comment made no sense for you. When I wrote it, I was  
looking into the particulars of what/who eventually sends #value to aBlock  
in #ifEmpty: aBlock

  ^ self isEmpty ifTrue: aBlock

which intuitively cannot be False>>#ifTrue: (contrasting that to: who/what  
is NOT sending #value). Of course an exact examination of all implementors  
of #ifTrue: would be needed if #value would have been sent in the wrong  
case.

>> But let us be concerned about the quality of doc versus code, even in  
>> Squeak. Did you see how much time it took > 3 people for finding out  
>> *what* actually happens *where*. Would you expect that (bytecode view  
>> for finding out whether #ifTrue: is optimized away, for example as  
>> jumpFalse:) from the next newcomer to Squeak?
>
> If you are interested in finding out whether something gets inlined or  
> not? Absolutely.

I could not agree less ;-) However, a problem that remains to be solved  
is, how can users of the Squeak dev environment be made aware of possible  
inlining. Perhaps by an appropriate comment <grin />

> It's the only sure way to find out and the sooner you learn about it,  
> the better. Sure, improving the comment will help, but if you want to  
> find out the truth of the situation there is no avoiding the bytecode  
> view.

Absolutely.

/Klaus

> Cheers,
>    - Andreas
>
>