[Pharo-project] 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
On 10 October 2010 15:39, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> 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.
"Igor" == Igor Stasenko <siguctua@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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@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
On Sun, 10 Oct 2010, Randal L. Schwartz wrote:
"Igor" == Igor Stasenko <siguctua@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?
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 <merlyn@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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
An excellent point about ambiguity. The two examples process ifNotNil:#terminate and something ifTrue:1 ifFlalse:0 appear to ask for perform and assign, respectively. Writing the brackets for the latter is not a big chore, and the first example is solved with a new message (#terminateMe) understood by both Process (self #terminate) and UndefinedObject (noop). Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Randal L. Schwartz [merlyn@stonehenge.com] Sent: Sunday, October 10, 2010 10:34 AM To: Igor Stasenko Cc: Pharo Development; The general-purpose Squeak developers list Subject: Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument
"Igor" == Igor Stasenko <siguctua@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. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 10 October 2010 17:34, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
"Igor" == Igor Stasenko <siguctua@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 ].
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@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.
On Sun, 10 Oct 2010, Igor Stasenko wrote:
On 10 October 2010 17:34, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
"Igor" == Igor Stasenko <siguctua@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@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.
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@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@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@stonehenge.com> wrote:
"Igor" == Igor Stasenko <siguctua@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@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.
Nicolas, Sig, The problem is compiler inlining? That happens at compile time, right? :) Unless I am missing something, I see no reason to get upset about what you propose. The runtime cost from the added messages is decided when the code is compiled, and things that are currently inlined would go right on being that way, even after they are recompiled?? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, October 10, 2010 9:06 AM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument On 10 October 2010 15:39, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> 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. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Nicolas, Have you thought about using another message, something like #terminateIfRunning that you put in both Process and UndefinedObject? Then you can just send it w/o the test and w/o a compiler change. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Sunday, October 10, 2010 8:39 AM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Igor Stasenko -
Levente Uzonyi -
merlyn＠stonehenge.com -
Nicolas Cellier -
Schwab,Wilhelm K