Compiler pedantic about ifNotNil: argument
Locked
Compiler pedantic about ifNotNil: argument
 
|
The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block.
Thus we cannot write this xtream sentence process ifNotNil: #terminate. When the argument is not a block, Compiler should avoid inlining and just send a normal message. cheers Nicolas |
Re: Compiler pedantic about ifNotNil: argument
|
|
On 10 October 2010 15:39, Nicolas Cellier
<[hidden email]> wrote: > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > +1 i am also missing: someThing ifTrue: 1 ifFalse: 0 > cheers > > Nicolas > > -- Best regards, Igor Stasenko AKA sig. |
Re: Compiler pedantic about ifNotNil: argument
|
|
>>>>> "Igor" == Igor Stasenko <[hidden email]> 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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
On Sun, 10 Oct 2010, Randal L. Schwartz wrote:
>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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? The implementation is staightforward IMHO. If the receiver expects a niladic block, then the argument is returned. If the receiver can accept a niladic or a monadic block, then #cull: is sent to the argument. If the receiver expects a monadic block, then #value: is sent to the argument. This works perfercly with blocks. Keyword selector symbols are equivalent with monadic blocks in this case, so Symbol >> #cull: can be implemented as ^argument perform: self. For other symbols #cull: is meaningless and #perform: will raise an error. Levente > > Please don't add so much dwimmery here. I like it that Smalltalk is > fairly strict with these basic forms. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
On 10/10/2010 10:55 AM, Levente Uzonyi wrote:
> On Sun, 10 Oct 2010, Randal L. Schwartz wrote: > >>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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? > > The implementation is staightforward IMHO. > If the receiver expects a niladic block, then the argument is returned. If the receiver can accept a niladic or a > monadic block, then #cull: is sent to the argument. If the receiver expects a monadic block, then #value: is sent to > the argument. This works perfercly with blocks. > > Keyword selector symbols are equivalent with monadic blocks in this case, so Symbol >> #cull: can be implemented as > ^argument perform: self. For other symbols #cull: is meaningless and #perform: will raise an error. > > > Levente > But the argument against it is not about implementation, it is about readability, that's where it introduces ambiguity and gratuitous incompatibility with other dialects. Sugar is bad for you in your food, let's be conservative with it in our language as well. If all we want is to type less, we might as well drop keyword selectors (we could just have the colons) and use some kind of Hungarian notation (peace, Levente :) ) for identifiers Florin |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
Am 2010-10-10 um 18:30 schrieb Florin Mateoc:
> On 10/10/2010 10:55 AM, Levente Uzonyi wrote: >> On Sun, 10 Oct 2010, Randal L. Schwartz wrote: […] >> >> > > But the argument against it is not about implementation, it is about readability, that's where it introduces ambiguity > and gratuitous incompatibility with other dialects. > Sugar is bad for you in your food, let's be conservative with it in our language as well. > If all we want is to type less, we might as well drop keyword selectors (we could just have the colons) and use some > kind of Hungarian notation (peace, Levente :) ) for identifiers Full ACK So Long, -Tobias |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Randal L. Schwartz
On 10 October 2010 17:34, Randal L. Schwartz <[hidden email]> wrote:
>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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 ]. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[hidden email]> <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. |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Tobias Pape
2010/10/10 Tobias Pape <[hidden email]>:
> Am 2010-10-10 um 18:30 schrieb Florin Mateoc: >> On 10/10/2010 10:55 AM, Levente Uzonyi wrote: >>> On Sun, 10 Oct 2010, Randal L. Schwartz wrote: > […] >>> >>> >> >> But the argument against it is not about implementation, it is about readability, that's where it introduces ambiguity >> and gratuitous incompatibility with other dialects. >> Sugar is bad for you in your food, let's be conservative with it in our language as well. >> If all we want is to type less, we might as well drop keyword selectors (we could just have the colons) and use some >> kind of Hungarian notation (peace, Levente :) ) for identifiers > > > Full ACK > > So Long, > -Tobias > > I don't follow the argument of readability. This leads to more readable code, with less {[()]} parasit. About ambiguity, it might traverse our spirit, but my original example was very intention revealing. process ifNotNil: #terminate. It's quite natural to associate the words (process terminate) in above sentence. Since ^#terminate makes no sense in this context, why should we fall into this interpretation ? About portability, it remains to see. The fun is that it's by porting VW code that I found this uncompatibility :) Nicolas |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
On 10 October 2010 20:10, Nicolas Cellier
<[hidden email]> wrote: >> > > I don't follow the argument of readability. This leads to more > readable code, with less {[()]} parasit. > About ambiguity, it might traverse our spirit, but my original example > was very intention revealing. > > process ifNotNil: #terminate. > > It's quite natural to associate the words (process terminate) in above sentence. > Since ^#terminate makes no sense in this context, why should we fall > into this interpretation ? > so, answer yourself, what intent of writing things like that: process ifNotNil: TheVariable and you suggest that if object, which sits in TheVariable, is symbol, then it has to #perform upon process as receiver, and if not, then what? > About portability, it remains to see. The fun is that it's by porting > VW code that I found this uncompatibility :) > > Nicolas > > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Florin Mateoc
On Sun, 10 Oct 2010, Florin Mateoc wrote:
> On 10/10/2010 10:55 AM, Levente Uzonyi wrote: >> On Sun, 10 Oct 2010, Randal L. Schwartz wrote: >> >>>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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? >> >> The implementation is staightforward IMHO. >> If the receiver expects a niladic block, then the argument is returned. If the receiver can accept a niladic or a >> monadic block, then #cull: is sent to the argument. If the receiver expects a monadic block, then #value: is sent to >> the argument. This works perfercly with blocks. >> >> Keyword selector symbols are equivalent with monadic blocks in this case, so Symbol >> #cull: can be implemented as >> ^argument perform: self. For other symbols #cull: is meaningless and #perform: will raise an error. >> >> >> Levente >> > > But the argument against it is not about implementation, it is about readability, that's where it introduces ambiguity > and gratuitous incompatibility with other dialects. I agree about readability when symbols are used where monadic blocks are not expected. I'm not sure about compatibility with other dialects. From Nicolas' mail I get that it's compatible with VW. > Sugar is bad for you in your food, let's be conservative with it in our language as well. It's not really sugar. This change allows these selectors to be used as any other selector. > If all we want is to type less, we might as well drop keyword selectors (we could just have the colons) and use some > kind of Hungarian notation (peace, Levente :) ) for identifiers :) Levente > > Florin > > |
Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Igor Stasenko
2010/10/10 Igor Stasenko <[hidden email]>:
> On 10 October 2010 20:10, Nicolas Cellier > <[hidden email]> wrote: >>> >> >> I don't follow the argument of readability. This leads to more >> readable code, with less {[()]} parasit. >> About ambiguity, it might traverse our spirit, but my original example >> was very intention revealing. >> >> process ifNotNil: #terminate. >> >> It's quite natural to associate the words (process terminate) in above sentence. >> Since ^#terminate makes no sense in this context, why should we fall >> into this interpretation ? >> > > so, answer yourself, what intent of writing things like that: > > process ifNotNil: TheVariable > depends if TheVariable can understand #cull: If not, then open the debugger... You can try it in updated trunk now. Nicolas > and you suggest that if object, which sits in TheVariable, is symbol, then > it has to #perform upon process as receiver, and if not, then what? > >> About portability, it remains to see. The fun is that it's by porting >> VW code that I found this uncompatibility :) >> >> Nicolas >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: Compiler pedantic about ifNotNil: argument
|
|
In reply to this post by Igor Stasenko
On Sun, 10 Oct 2010, Igor Stasenko wrote:
> On 10 October 2010 17:34, Randal L. Schwartz <[hidden email]> wrote: >>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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 ]. the type of the argument? Levente > > >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >> <[hidden email]> <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. > > |
Re: Compiler pedantic about ifNotNil: argument
|
|
2010/10/10 Levente Uzonyi <[hidden email]>:
> On Sun, 10 Oct 2010, Igor Stasenko wrote: > >> On 10 October 2010 17:34, Randal L. Schwartz <[hidden email]> >> wrote: >>>>>>>> >>>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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? > true ifTrue sends #value to its argument. What is wrong with such kind of dispatch? But okay.. i see that foo ifNotNil: #bar is more userful in a form, when it leads to foo perform: #bar rather than just returning #bar. > > Levente > >> >> >>> >>> -- >>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >>> 0095 >>> <[hidden email]> <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. >> > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Compiler pedantic about ifNotNil: argument
|
|
On Sun, 10 Oct 2010, Igor Stasenko wrote:
> 2010/10/10 Levente Uzonyi <[hidden email]>: >> On Sun, 10 Oct 2010, Igor Stasenko wrote: >> >>> On 10 October 2010 17:34, Randal L. Schwartz <[hidden email]> >>> wrote: >>>>>>>>> >>>>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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? >> > > true ifTrue sends #value to its argument. What is wrong with such kind > of dispatch? every object? Object >> cull: anObject ^self Levente > > But okay.. i see that > > foo ifNotNil: #bar > > is more userful in a form, when it leads to > > foo perform: #bar > > rather than just returning #bar. > > >> >> Levente >> >>> >>> >>>> >>>> -- >>>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >>>> 0095 >>>> <[hidden email]> <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. >>> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: Compiler pedantic about ifNotNil: argument
|
|
2010/10/10 Levente Uzonyi <[hidden email]>:
> On Sun, 10 Oct 2010, Igor Stasenko wrote: > >> 2010/10/10 Levente Uzonyi <[hidden email]>: >>> >>> On Sun, 10 Oct 2010, Igor Stasenko wrote: >>> >>>> On 10 October 2010 17:34, Randal L. Schwartz <[hidden email]> >>>> wrote: >>>>>>>>>> >>>>>>>>>> "Igor" == Igor Stasenko <[hidden email]> 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? >>> >> >> true ifTrue sends #value to its argument. What is wrong with such kind >> of dispatch? > > That kind of dispatch is ok, but would you really add this method to every > object? > > Object >> cull: anObject > > ^self > That's a good question. I'm not sure. Object >> cull: anObject "receiver should behave as a monadic block" ^self > > Levente > >> >> But okay.. i see that >> >> foo ifNotNil: #bar >> >> is more userful in a form, when it leads to >> >> foo perform: #bar >> >> rather than just returning #bar. >> >> >>> >>> Levente >>> >>>> >>>> >>>>> >>>>> -- >>>>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >>>>> 0095 >>>>> <[hidden email]> <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. >>>> >>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Compiler pedantic about ifNotNil: argument
|
|
Okay,
lets assume, we using #cull: for ifNotNil: argument. Then how about ifNil:ifNotNil ? What you expect from given example: self perform: (object ifNil: #foo ifNotNil: #bar) ? -- Best regards, Igor Stasenko AKA sig. |
Re: Compiler pedantic about ifNotNil: argument
|
|
On Sun, 10 Oct 2010, Igor Stasenko wrote:
> Okay, > lets assume, we using #cull: for ifNotNil: argument. > > Then how about ifNil:ifNotNil ? > > What you expect from given example: > > self perform: (object ifNil: #foo ifNotNil: #bar) If object is nil, then the value of [self perform: #foo], else [self perform: (object perform: #bar)]. Levente > > ? > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: Compiler pedantic about ifNotNil: argument
|
|
On 10 October 2010 21:36, Levente Uzonyi <[hidden email]> wrote:
> On Sun, 10 Oct 2010, Igor Stasenko wrote: > >> Okay, >> lets assume, we using #cull: for ifNotNil: argument. >> >> Then how about ifNil:ifNotNil ? >> >> What you expect from given example: >> >> self perform: (object ifNil: #foo ifNotNil: #bar) > > If object is nil, then the value of [self perform: #foo], else [self > perform: (object perform: #bar)]. > but if you don't know what inside, what will be a least surprising and most expected behavior? > > Levente > >> >> ? >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: Compiler pedantic about ifNotNil: argument
|
|
On Mon, 11 Oct 2010, Igor Stasenko wrote:
> On 10 October 2010 21:36, Levente Uzonyi <[hidden email]> wrote: >> On Sun, 10 Oct 2010, Igor Stasenko wrote: >> >>> Okay, >>> lets assume, we using #cull: for ifNotNil: argument. >>> >>> Then how about ifNil:ifNotNil ? >>> >>> What you expect from given example: >>> >>> self perform: (object ifNil: #foo ifNotNil: #bar) >> >> If object is nil, then the value of [self perform: #foo], else [self >> perform: (object perform: #bar)]. >> > oh really? it is because you defined so. It's not just me. It's like this in VW and Pharo (1.2). > but if you don't know what inside, what will be a least surprising and > most expected behavior? Did you mean: What happens if I don't know what the method will do? If I know that a method expects a monadic block, but I'm not sure if it will accept a symbol (because it sends it may send a message other than #value: or #cull:) and I don't want to check it out, then I will use a block and that will work sure. Levente > > >> >> Levente >> >>> >>> ? >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |