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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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.

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

personnally I do not like this form
What does it do?

>    process ifNotNil: #terminate.


for me it means passes the symbol #terminate as argument to the method ifNotNil:
If it has a more magical behavior then I do not know it.

Stef



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

On 10 October 2010 16:13, Stéphane Ducasse <[hidden email]> wrote:
> personnally I do not like this form
> What does it do?
>
>>    process ifNotNil: #terminate.
>

here the test case for it:

| process answer |

process := Object new.

answer := process ifNotNil: #terminate.

self assert: answer == #terminate.




--
Best regards,
Igor Stasenko AKA sig.

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

Yes, this can be surprising at first.
But I think this is because you read it with a preformated Smalltalk
mind, rather than just english.
 it's just like:

   (1 to: 10) select: #even.

Nicolas

2010/10/10 Stéphane Ducasse <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Oct 10, 2010, at 3:17 PM, Igor Stasenko wrote:

all that to avoid to have

        ifNotNil: [#terminate]

I would not change the ifNotNil: for that.
But make the compiler smarter

Stef


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

2010/10/10 Igor Stasenko <[hidden email]>:
Ah, yes, I did not interpret it the same...
I asked my son, which is not a Smalltalker, what he understood, and it
was (process terminate) not (^#terminate).

Nicolas

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

>>>>> "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

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

On Sun, 10 Oct 2010, Randal L. Schwartz wrote:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Nicolas Cellier [[hidden email]]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
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
<[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.

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

_______________________________________________
Pharo-project mailing list
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Randal L. Schwartz [[hidden email]]
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 <[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

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

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

On 10 October 2010 17:34, Randal L. Schwartz <[hidden email]> wrote:
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.

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

On Sun, 10 Oct 2010, Igor Stasenko wrote:
How would you implement #ifNotNil: to reflect this? Would you dispatch on
the type of the argument?


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

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: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]]
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:

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


Levente

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

On Oct 10, 2010, at 3:07 PM, Igor Stasenko wrote:

I hate this idea.
Let the compiler doing optimizations and please do not mix implementation and language design.
The ***semantics*** of iftrue: is to get a thunk (in scheme parlance) something whose evaluation is blocked.
1 is not that!

Now the compiler could be smart and inline whatever.

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

On 10 October 2010 23:25, Stéphane Ducasse <[hidden email]> wrote:
hmm.. what is wrong with sending real #ifTrue:ifFalse: message to boolean,
if compiler can't inline it?

or you think a following is a good way to write a code:

blockA := [self foo ].
blockB := [ self bar ].

self zork ifTrue: [ blockA value] ifFalse: [ blockB value ]

where you can just write:

self zork ifTrue: blockA ifFalse: blockB

?
In any way, passing anything else than block literal as argument should work.
This is smalltalk, not C with static types.

> Now the compiler could be smart and inline whatever.
>
> Stef
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

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

>
>
> ?
> In any way, passing anything else than block literal as argument should work.

You mean in the implementation or in the semantics?
Read my mail.
This is a question of semantics. The argument of iftrue:ifFalse: are thunk (piece of code with frozen execution).

> This is smalltalk, not C with static types.

consistency and elegance as nothing to do with absence of static types.
With such a change we can break a lot of uniformity and break potential type inferencers.
And I do not see the advantage, beside having a clunky system.

Stef


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

On Oct 10, 2010, at 3:13 08PM, Stéphane Ducasse wrote:

It's exactly the same as using collection do: #something.

FWIW, in 1.2 we already included the compiler changes Levente suggested to me to remove this restriction, so

nil ifNotNil: #squared -> nil
4 ifNotNil: #squared -> 16.

I.e. it already does what Nicolas suggested. (As per the Symbol>>#cull: thread)

Cheers,
Henry


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

This is still not really readable compared to
        4 ifNotNil: [:rec | rec squared]

For select: #even why not

Now to me this looks like a hack and again it works because now Symbol are valuable objects.
Too many hacks will only make the system more hackish.
And especially the
        iftrue: 'foo' ifFalse: 'zork'

In Smalltalk this is simple you ut bracket when you do not know if a part should/will be executed.
Now with such change this is not the case anymore.
I think that we are focusing on the wrong point. Changing the language that way does not
bring anything really useful.

And I would veto such usage in the core for consistency reason.

Stef


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