Lex,

On Fri, 19 Jan 2001 18:28:39 -500 "Lex Spoon" <lex at cc.gatech.edu> wrote:
>> 
>> >	5) Readability again. My eyes catch the [].
>> 
>> And what does the [] tell you?
>> A - That you have encountered one of those idiosyncratic messages, #ifTrue:#ifFalse:, which happens to be a bit peculiar as to what kind of arguments it will accept and how they are written?
>> B - That the programmer has decided to defer evaluation of the code within until such time as it is really needed?
>> C - Something else?
>> 
>> My eyes translate the [] as B. Unnecessary brackets do as little for readability in my eyes as unnecessary parentheses. I would prefer the brackets to mean: "Don't evaluate this code right now. just package it up so that it can be evaluated later, if need be."
>> 
>
>To be pedantic, this is precisely what the [] *does* mean in
>ifTrue:ifFalse: -- the code is packaged up and is possibly evaluated
>later.
>
>Agreed that it's kind of annoying to be explicit about things like that,
>but it *is* what's going on.

I agree. My point was that being required in the case of this small family of messages to use a literal block or a simple instance variable is a concession to the compiler writing gods. Other messages like #do:, #select:, etc. enforce no such restriction. This makes it harder, rather than easier to explain, IMHO.

My disquiet with the implementation of #ifTrue:.. is that the brackets are required even when it is of no concern to me whether the code gets evaluated unnecessarily or not. Or even when I want both to be evaluated. Consider:

	a := a + 1.
	b := b + 1.
	^cond ifTrue: [a] ifFalse: [b]

could be written as

	^cond ifTrue: (a _ a + 1) ifFalse: (b _ b + 1)

if the compiler were a little friendlier to harder-to-optimize code and Object understood #value. If we changed the selector in the example to

	^cond eitherThis: (a _ a + 1) orThat: (b _ b + 1)

we sould have something syntactically equivalent and probably no one would bat an eye. We seem to be hung up on special treatment for #ifTrue:ifFalse: and I don't quite understand why.


>
>
>> 
>> >		cond ifTrue: 1->2 ifFalse: 2->2
>> >	would return 2 in both cases!
>> 
>> Well, it basically does that now.
>
>The point is, when you start, it looks so cool being able to do this:
>
>	cond ifTrue: 2 ifFalse: 3
>
>but the idiom breaks down into the general case very quickly, and it's
>not even a clean break -- there are plenty of border cases for people to
>get snagged on.  The above is one of them, and I'd hate trying to
>explain to a newbie what was happening.

If were are trying to explain things to newbies, I suspect there a a bunch of things we wouldn't show them on the first day, but that does not argue for a language limited to newbie features.

Cheers,
Bob