It sounds like a double dispatch that, as that enables, gives the behavior one 
would want in either case:  evaluate the block and return its value, just give 
the value of a magnitude (evaluating same is trivial), etc.  The ambiguity 
argument got me, but with a dispatch along the way, I think that can be fixed.

Two POTENTIAL concerns are that it might hurt performance (perhaps only if 
abused), and that it effectively creates more syntax.  I am a little sensitive 
to the latter because I have been doing a lot with R, which is quite sugary and 
all the harder to learn as a result.  Are we helping noobs by accepting blocks 
or objects that "magically" get evaluated?  Loosely related, in areas in which 
inlining helps, people who have learned to deviate from optimizable constructs 
could end up writing slower code than they might have before the change??

Bill




________________________________________
From: [email protected] 
[[email protected]] On Behalf Of Levente Uzonyi 
[[email protected]]
Sent: Sunday, October 10, 2010 1:21 PM
To: The general-purpose Squeak developers list
Cc: Pharo Development
Subject: Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil:     
argument

On Sun, 10 Oct 2010, Igor Stasenko wrote:

> On 10 October 2010 17:34, Randal L. Schwartz <[email protected]> wrote:
>>>>>>> "Igor" == Igor Stasenko <[email protected]> writes:
>>
>> Igor> i am also missing:
>>
>> Igor> someThing ifTrue: 1 ifFalse: 0
>>
>> Down that path lies ambiguity though.
>>
>> If you had
>>
>>  actionSymbol := aBoolean ifTrue: #doThis else: #doThat.
>>
>> do you want the symbol assigned, or performed?
>>
>> Please don't add so much dwimmery here.  I like it that Smalltalk is
>> fairly strict with these basic forms.
>
> what dwimmery you talking about?
>
> b :=  [ 15 ].
> a :=  [ 16 ].
>
> true ifTrue: a ifFalse: b
> 16
>
> as well as:
>
> b :=  15 .
> a :=  16 .
>
> true ifTrue: a ifFalse: b
> 16
>
> works well.
>
>
> In this way,
>
> answer := process ifNotNil: #terminate.
>
> should be equivalent to:
>
> answer := process notNil ifTrue: #terminate
>
> but not to:
>
> answer := process notNil ifTrue: [ process terminate ].

How would you implement #ifNotNil: to reflect this? Would you dispatch on
the type of the argument?


Levente

>
>
>>
>> --
>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
>> <[email protected]> <URL:http://www.stonehenge.com/merlyn/>
>> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
>> See http://methodsandmessages.posterous.com/ for Smalltalk discussion
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to