I know and again, I insist, this is talking 'optimization', and not
'conceptual'. For the optimization you mention, certain sacrifices were
made. For example, one of my colleagues had serieus trouble with this for
implementing a RMI-like scheme, because the class message was inlined that
way. Even though, this does not mean, again, that on a conceptual level it
is not clean...... That's what I meant.


On 19-01-2001 11:14 PM, "Alejandro F. Reimondo"
<aleReimondo at smalltalking.net> wrote:

> Roel,
>> This means that, #ifTrue:ifFalse: is just another
>> message, just like #at:put: or #myNiftyAction:.
> #ifTrue:ifFalse: and all the ifXXXX:... messages
> are not "just another message", because they
> are inlined by the compiler.
> 
> If you evaluate:
> 12 factorial ifTrue: [ 3 ] ifFalse: [ 5 ]
> You will see that the error is handled by the VirtualMachine
> sending the message #mustBeBoolean
> The VM does NOT re-send the message #ifTrue:ifFalse:
> and doesNOT generate a #doesNotUnderstand:
> error message !
> 
> If you implement an instance method for #ifTrue:ifFalse:
> in Number class you will see that the method is NOT activated.
> The method lookup is not executed for #ifXXXX:... messages
> because they are inlined by the compiler.
> 
> If you want that anObject (an object of a simple model class)
> works for #ifTrue:ifFalse: (and all #ifXXX:... messages)
> you can implement a method for #mustBeBoolean
> returning true if the receiver act as aKindOf True
> (see Object>>#mustBeBoolean).
> If you implement the #mustBeBoolean message you can
> have objects acting as true & false; BUT with no implementation
> for #ifXXXX: messages.
> 
> I think that this kind of "anormal" behavior is present because
> the VM can not build (at low cost) a context from inlined code;
> and it is requiered if it want to resend the #ifXXXX:... message
> to the receiver (if not aBoolean).
> 
> Another important point is that ALL smalltalks works that way;
> if we change the behavior of the VM to resend the #ifXXXX:...
> message we provably will be incompatible with other Smalltalks.
> 
> Cheers,
> Ale.
> 
> 
> 
> ----------
> De:     Roel Wuyts[SMTP:rwuyts at vub.ac.be]
> Responder a:     squeak at cs.uiuc.edu
> Enviado el:     Viernes 19 de Enero de 2001 04:52
> Para:     squeak at cs.uiuc.edu
> Asunto:     Re: Some Self ideas
> 
> For me, one of the things I like about Smalltalk is its *elegancy*, on a
> *conceptual level*. This means that, #ifTrue:ifFalse: is just another
> message, just like #at:put: or #myNiftyAction:. This also means that I know
> that when I use a block somewhere, I am passing an argument for which I
> want/need *delayed evaluation*. This is consistent throughout the complete
> implementation, for all the places where I pass something that does not need
> to be evaluated immediately. So, the rule is very simple, clear and elegant:
> need to pass something that you do not want to be calculated immediately ->
> use a block; want it to be calculated immediately -> do not use a block.
> 
> As far as I am concerned, this proposal -while looking 'harmless' at first
> sight- removes that clearness and elegancy. All of a sudden, I can in some
> cases pass an argument for which I normally want to use delayed evaluation,
> but I do not need to anymore. Try explaining this to newcomers in Smalltalk,
> on a conceptual level. Sure you can give them lots of examples where it
> saves you a few lines of code, but not a simple conceptual explanation you
> use systemwide: use a block whenever you want delayed evaluation.
> 
> Think conceptually !
> 
> 
> 
> On 18-01-2001 11:30 PM, "Bob Arning" <arning at charm.net> wrote:
> 
>> Bijan,
>> 
>> On Thu, 18 Jan 2001 15:31:29 -0500 (EST) Bijan Parsia <bparsia at email.unc.edu>
>> wrote:
>>> I suppose if it were inlined such that the "c doSomething" and "c
>>> doSomethignElse" were only conditionally evalated, then the worry about
>>> delayed evaluation would be moot. But my goodness! At what *price*?
>>> 1) Putting a bigger wedge between #ifTrue:ifFalse: etc. and
>>> normal messages. They would *depend* CRUCIALLY on the optimization
>>> for their *semantics*.
>> 
>> Only if you decide to keep the optimization.
>> 
>>> 3) *screwing* with precedence (since *all of sudden*, the keyword
>>> messages would get evaluated before the unary one. But only in
>>> these cases!
>> 
>> I missed that suggestion.
>> 
>>> 4) It's even worse if the "constants *or* variable" interpretation
>>> is considered best practice, since the *variable* might contain a
>>> block sometimes! e.g.:
>>> 
>>> | aNumber aBlock |
>>> aNumber := 2.
>>> aBlock := [self incrementAndReturnCounter].
>>> 
>>> cond ifTrue: aNumber ifFalse aBlock.
>>> cond ifTrue: self incrementAndReturnCounter ifFalse: aBlock.
>>> 
>>> Bleah! Who knows what's supposed to happen on this scenario.
>>> Frankly, I would think that using variables (instead of explicit
>>> blocks) is generally bad style, though important in some cases.
>>> This change would make that horribly dangerous.
>> 
>> Absent optimization by the compiler, it's easy to figure out. A proper
>> optimization would produce the same results, just faster.
>> 
>>> 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."
>> 
>>> 6) Adding yet another bunch of methods to Object
>> 
>> IIRC, it is ONE method.
>> 
>>> *plus* dealing
>>> with the *other* classes that implment a #value: (Association
>>> anyone?) Why remove such a useful keyword from the rest of the
>>> system?
>> 
>> What keyword has anyone suggested removing? I missed that part.
>> 
>>> cond ifTrue: 1->2 ifFalse: 2->2
>>> would return 2 in both cases!
>> 
>> Well, it basically does that now.
>> 
>> | t f |
>> t _ 1->2.
>> f _ 2->2.
>> {
>> 'using Associations'.
>> true ifTrue: t ifFalse: f.
>> false ifTrue: t ifFalse: f.
>> } inspect.
>> 
>> t _ MessageSend receiver: #(1 2) selector: #size.
>> f _ MessageSend receiver: #(2 3) selector: #size.
>> {
>> 'using MessageSends'.
>> true ifTrue: t ifFalse: f.
>> false ifTrue: t ifFalse: f.
>> } inspect.
>> 
>> 
>>> For what? The occassional elimination of *four frigging keystrokes*?
>>> 
>>>> I like the possibility of eliminating the brackets when they aren't
>>>> serving a real purpose,
>>> 
>>> *Why*? They're *always* serving a readability purpose. And a clarity
>>> one. And if you don't like the 4 keystrokes then you can modify the
>>> control-t command to add them in.
>> 
>> You may like them, but others find them to be just noise when they are not
>> adding additional information.
>> 
>>>> but I can see where it might raise the
>>>> confusion level.
>>> 
>>> *Might*?
>>> 
>>> The suggestion is just broken as proposed, and any purported value is *so*
>>> minimal it's hard to see how it could even get on the table. Not to
>>> mention *gratuitous* incompatibility with all other Smalltalks, the ANSI
>>> standard, etc.
>> 
>> Since I don't have the standard in front of me, which part breaks the
>> standard?
>> 
>> - adding #value to Object?
>> - writing a compiler to that generates
>> 
>> push a
>> push b
>> push c
>> send: #ifTrue:ifFalse:
>> 
>> whenever it encounters
>> 
>> a ifTrue: b ifFalse: c
>> 
>>> Can we declare this dead yet? I haven't seen *any* positive argument
>>> beyond the saving of four keystrokes which is totally slain by readability
>>> and compatibility considerations *before* getting into the even more
>>> devestating objections.
>> 
>> Dead? In Smalltalk? Nothing ever dies in Smalltalk!
>> 
>> Cheers,
>> Bob
>> 
> 
> --
> Roel Wuyts                    Programming Technology Lab
> rwuyts at vub.ac.be              Vrije Universiteit Brussel
> http://prog.vub.ac.be/~rwuyts
> Webmaster of European Smalltalk User Group: www.esug.org
> 
> 
> 

--
Roel Wuyts                    Programming Technology Lab
rwuyts at vub.ac.be              Vrije Universiteit Brussel
http://prog.vub.ac.be/~rwuyts
Webmaster of European Smalltalk User Group: www.esug.org