[Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sun Oct 10 14:36:27 EDT 2010


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: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves at elte.hu]
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 <merlyn at stonehenge.com> wrote:
>>>>>>> "Igor" == Igor Stasenko <siguctua at gmail.com> 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
>> <merlyn at stonehenge.com> <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.
>
>




More information about the Pharo-dev mailing list