[ANN] SuffixConditionals

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] SuffixConditionals

Randy Coulman

I have just released SuffixConditionals which allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store Repository. A snapshot of the current version is also on GitHub.

The full release announcement is on my blog, Courageous Software

--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Michael Lucas-Smith-2
Neat.

Michael

On 23 Apr 2014, at 12:27 am, Randy Coulman <[hidden email]> wrote:

I have just released SuffixConditionals which allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store Repository. A snapshot of the current version is also on GitHub.

The full release announcement is on my blog, Courageous Software

--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Arden-8
In reply to this post by Randy Coulman

Hi Randy;

 

It is always good to see ideas and have options for clear, simple expression.

 

Thanks for sharing! 

 

Regards

 

               Arden

               [hidden email]

               Cincom Smalltalk Product manager

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Tuesday, April 22, 2014 10:27 AM
To: VW NC
Subject: [vwnc] [ANN] SuffixConditionals

 

I have just released SuffixConditionals which allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store Repository. A snapshot of the current version is also on GitHub.

The full release announcement is on my blog, Courageous Software

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Steffen Märcker
In reply to this post by Randy Coulman
Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as  
well.

   [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push  
them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

> I have just released
> SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
> allows for Ruby-like suffix conditionals in Visualworks Smalltalk.
>
> SuffixConditionals adds #if: and #unless methods to BlockClosure,  
> allowing
> you to write statements such as:
>
> [process stop] if: process isRunning
>
> and
>
> [process start] unless: process isRunning
>
> SuffixConditionals is available in the Cincom Public Store
> Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
> A snapshot of the current version is also on
> GitHub<https://github.com/randycoulman/SuffixConditionals>
> .
>
> The full release announcement is on my blog, Courageous
> Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

diff_SuffixConditonals-Tests.st (1K) Download Attachment
diff_SuffixConditonals.st (690 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Randy Coulman

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.

Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.

Randy



On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:
Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Steffen Märcker
Hi Randy,

I think #if:else: fits the picture if you are primarily interested in a
conditional value. For example,

> 'n is ' , ([#odd] if: n odd else: [#even])

reads clearer (at least for me) than the conventional

> 'n is ' , (n odd ifTrue: [#odd] ifFalse: [#even])

On the other hand, as always with those kind of extensions, readability
can be highly debatable.

Besides this, one could implement #if: and #if:else: in Object as well, to
simply return the receiver or the second argument:

> if: aBoolean else: anObject
>
>  ^aBoolean ifTrue: [self] ifFalse: [anObject]

Than the example above would be even simpler:

> 'n is ' , (#odd if: n odd else: #even)

Regards, Steffen


PS: I totally agree that #unless:else: would be evil. ;)



Am 23.04.2014, 20:16 Uhr, schrieb Randy Coulman <[hidden email]>:

> Hi, Steffen,
>
> I appreciate your interest and desire to contribute to this. That’s  
> awesome!
>
> That said, I would rather not include this extension. I think it’s less
> readable than the standard:
>
> n odd ifTrue: [#odd] ifFalse: [#even]
>
> In my mind, SuffixConditionals only make sense when the focus of a line  
> of
> code should be on the action more than the condition. But with the
> #if:else:variant, there are two actions and they’re now separated by
> the condition.
>
> Is there a case where you would find a suffix #if:else: more readable  
> than
> the same thing with #ifTrue:ifFalse:?
>
> I’m open to having my mind changed if others feel strongly about it, but  
> my
> initial reaction is not to include it.
>
> My other concern is that adding #if:else: will make someone want to add
> #unless:else:, and that’s just pure evil :-). Ruby has that variant, and
> I’ve only ever seen Rubyists rant against anyone who uses it.
>
> Randy
>
>
> On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:
>
>> Hi Randy!
>>
>> Neat stuff! I've added a Pythonic #if:else: message which I find handy  
>> as
>> well.
>>
>>   [#odd] if: (n odd) else: [#even]
>>
>> Find the changes attached. If you don't have objections I'd like to push
>> them to the repo later today. Agreed?
>>
>> Regards,
>> Steffen
>>
>> Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:
>>
>>  I have just released
>>> SuffixConditionals<https://github.com/randycoulman/SuffixConditionals
>>> >which
>>> allows for Ruby-like suffix conditionals in Visualworks Smalltalk.
>>>
>>> SuffixConditionals adds #if: and #unless methods to BlockClosure,  
>>> allowing
>>> you to write statements such as:
>>>
>>> [process stop] if: process isRunning
>>>
>>> and
>>>
>>> [process start] unless: process isRunning
>>>
>>> SuffixConditionals is available in the Cincom Public Store
>>> Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+
>>> Store+Repository>.
>>> A snapshot of the current version is also on
>>> GitHub<https://github.com/randycoulman/SuffixConditionals>
>>> .
>>>
>>> The full release announcement is on my blog, Courageous
>>> Software<http://randycoulman.com/blog/2014/04/22/suffix-
>>> conditionals-in-smalltalk/>
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Randy Coulman
Steffen,

If you want to publish it with a "branch" (non-integer) version number, I'll look at the code and merge it back to the trunk.

The Object implementation idea is interesting - I hadn't thought of that option.  But I don't think I'd add it.  The block delimiters aren't that much additional syntax noise, and they give you conditional/deferred evaluation.

Randy



On Thu, Apr 24, 2014 at 12:07 AM, Steffen Märcker <[hidden email]> wrote:
Hi Randy,

I think #if:else: fits the picture if you are primarily interested in a
conditional value. For example,

'n is ' , ([#odd] if: n odd else: [#even])

reads clearer (at least for me) than the conventional

'n is ' , (n odd ifTrue: [#odd] ifFalse: [#even])

On the other hand, as always with those kind of extensions, readability
can be highly debatable.

Besides this, one could implement #if: and #if:else: in Object as well, to
simply return the receiver or the second argument:

if: aBoolean else: anObject

 ^aBoolean ifTrue: [self] ifFalse: [anObject]

Than the example above would be even simpler:

'n is ' , (#odd if: n odd else: #even)

Regards, Steffen


PS: I totally agree that #unless:else: would be evil. ;)



Am 23.04.2014, 20:16 Uhr, schrieb Randy Coulman <[hidden email]>:


Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less
readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of
code should be on the action more than the condition. But with the
#if:else:variant, there are two actions and they’re now separated by
the condition.

Is there a case where you would find a suffix #if:else: more readable than
the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my
initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add
#unless:else:, and that’s just pure evil :-). Ruby has that variant, and
I’ve only ever seen Rubyists rant against anyone who uses it.

Randy


On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as
well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push
them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

 I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals
>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+
Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-
conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Paul Baumann
In reply to this post by Randy Coulman

It is nice, but I wouldn't use it unless it was compiler-optimized to be as efficient as #ifTrue:.

 

Be aware that debugging through this will be different. Be aware that there is a performance difference between the two approaches. The #ifTrue: is optimized by the compiler while the #if: pattern would often be a BlockClosure that maintains outer context.

 

Time microsecondsToRun: [10000000 timesRepeat: [

                [self yourself] if: true.

]]

 

256068

257670

253154

 

Time microsecondsToRun: [10000000 timesRepeat: [

                true ifTrue: [self yourself].

]]

 

57610

54798

46007

 

1 - (253154 / 46007) * -100.0

450.251

 

The relative difference is huge, but the cumulative cost is small enough to be ignored. Few would care about a cost like this, at least in VW. Be aware that there are object creation and disposal costs that are much higher in other dialects like GS/S. The relative difference is twice as bad on GS/S:

 

| t |

t := System timeNs.

10000000 timesRepeat: [[self yourself] if: true].

(System timeNs - t) // 1000.

 

3935243

3959995

3911631

 

| t |

t := System timeNs.

10000000 timesRepeat: [true ifTrue: [self yourself]].

(System timeNs - t) // 1000.

 

403045

401248

405734

 

1 - (3911631 / 401248) * -100.0

874.866

 

The complete avoidance of ComplexBlocks in GS/S for collection enumerations has commonly gained an 80% reduction in execution time in normal application code. That claim has met skepticism from even GemTalk development, but it is proven here by all our code. We use custom enumeration protocols to pass context as arguments into blocks so that they don't need to be copied with knowledge of outer context. The inefficiencies in kernel enumerations are tuned away, and because every execution is clean we are able to see significant application-level gains. It is not just that a ComplexBlock is used but how it is used that matters. It has to do with the cost of oop allocation and when the VM allows reclaim. ComplexBlocks used for enumeration have a higher hidden cost in GS/S than VW because garbage accumulates to affect performance.

 

Paul Baumann

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Wednesday, April 23, 2014 14:16
To: Steffen Märcker
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

 

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.

Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.

Randy

 

On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<<a href="http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public&#43;Store&#43;Repository" target="_blank">http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



 

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Steffen Märcker
In reply to this post by Randy Coulman
Hi Randy,

I've just published the code as 'SuffixConditionals (infix)'. Please let  
me know when you merged it into the trunk.

Best Regards,
Steffen


Am 24.04.2014, 17:35 Uhr, schrieb Randy Coulman <[hidden email]>:

> Steffen,
>
> If you want to publish it with a "branch" (non-integer) version number,
> I'll look at the code and merge it back to the trunk.
>
> The Object implementation idea is interesting - I hadn't thought of that
> option.  But I don't think I'd add it.  The block delimiters aren't that
> much additional syntax noise, and they give you conditional/deferred
> evaluation.
>
> Randy
>
>
>
> On Thu, Apr 24, 2014 at 12:07 AM, Steffen Märcker <[hidden email]> wrote:
>
>> Hi Randy,
>>
>> I think #if:else: fits the picture if you are primarily interested in a
>> conditional value. For example,
>>
>>  'n is ' , ([#odd] if: n odd else: [#even])
>>>
>>
>> reads clearer (at least for me) than the conventional
>>
>>  'n is ' , (n odd ifTrue: [#odd] ifFalse: [#even])
>>>
>>
>> On the other hand, as always with those kind of extensions, readability
>> can be highly debatable.
>>
>> Besides this, one could implement #if: and #if:else: in Object as well,  
>> to
>> simply return the receiver or the second argument:
>>
>>  if: aBoolean else: anObject
>>>
>>>  ^aBoolean ifTrue: [self] ifFalse: [anObject]
>>>
>>
>> Than the example above would be even simpler:
>>
>>  'n is ' , (#odd if: n odd else: #even)
>>>
>>
>> Regards, Steffen
>>
>>
>> PS: I totally agree that #unless:else: would be evil. ;)
>>
>>
>>
>> Am 23.04.2014, 20:16 Uhr, schrieb Randy Coulman <[hidden email]>:
>>
>>
>>  Hi, Steffen,
>>>
>>> I appreciate your interest and desire to contribute to this. That’s
>>> awesome!
>>>
>>> That said, I would rather not include this extension. I think it’s less
>>> readable than the standard:
>>>
>>> n odd ifTrue: [#odd] ifFalse: [#even]
>>>
>>> In my mind, SuffixConditionals only make sense when the focus of a  
>>> line of
>>> code should be on the action more than the condition. But with the
>>> #if:else:variant, there are two actions and they’re now separated by
>>> the condition.
>>>
>>> Is there a case where you would find a suffix #if:else: more readable  
>>> than
>>> the same thing with #ifTrue:ifFalse:?
>>>
>>> I’m open to having my mind changed if others feel strongly about it,  
>>> but
>>> my
>>> initial reaction is not to include it.
>>>
>>> My other concern is that adding #if:else: will make someone want to add
>>> #unless:else:, and that’s just pure evil :-). Ruby has that variant,  
>>> and
>>> I’ve only ever seen Rubyists rant against anyone who uses it.
>>>
>>> Randy
>>>
>>>
>>> On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]>  
>>> wrote:
>>>
>>>  Hi Randy!
>>>>
>>>> Neat stuff! I've added a Pythonic #if:else: message which I find  
>>>> handy as
>>>> well.
>>>>
>>>>   [#odd] if: (n odd) else: [#even]
>>>>
>>>> Find the changes attached. If you don't have objections I'd like to  
>>>> push
>>>> them to the repo later today. Agreed?
>>>>
>>>> Regards,
>>>> Steffen
>>>>
>>>> Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:
>>>>
>>>>  I have just released
>>>>
>>>>> SuffixConditionals<https://github.com/randycoulman/SuffixConditionals
>>>>> >which
>>>>> allows for Ruby-like suffix conditionals in Visualworks Smalltalk.
>>>>>
>>>>> SuffixConditionals adds #if: and #unless methods to BlockClosure,
>>>>> allowing
>>>>> you to write statements such as:
>>>>>
>>>>> [process stop] if: process isRunning
>>>>>
>>>>> and
>>>>>
>>>>> [process start] unless: process isRunning
>>>>>
>>>>> SuffixConditionals is available in the Cincom Public Store
>>>>> Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+
>>>>> Store+Repository>.
>>>>> A snapshot of the current version is also on
>>>>> GitHub<https://github.com/randycoulman/SuffixConditionals>
>>>>> .
>>>>>
>>>>> The full release announcement is on my blog, Courageous
>>>>> Software<http://randycoulman.com/blog/2014/04/22/suffix-
>>>>> conditionals-in-smalltalk/>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> vwnc mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>
>>>>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Randy Coulman
In reply to this post by Paul Baumann
Hi, Paul,

Yeah, I recognize the performance hit over the standard #ifTrue:/#ifFalse: - even mentioned it in the package comment and Readme.  I wouldn't use this in performance-critical places, but most of the time I'll choose expressiveness over performance until my profiler tells me I have a problem.

You are, of course, free to choose otherwise :-).

Randy



On Fri, Apr 25, 2014 at 8:13 AM, Paul Baumann <[hidden email]> wrote:

It is nice, but I wouldn't use it unless it was compiler-optimized to be as efficient as #ifTrue:.

 

Be aware that debugging through this will be different. Be aware that there is a performance difference between the two approaches. The #ifTrue: is optimized by the compiler while the #if: pattern would often be a BlockClosure that maintains outer context.

 

Time microsecondsToRun: [10000000 timesRepeat: [

                [self yourself] if: true.

]]

 

256068

257670

253154

 

Time microsecondsToRun: [10000000 timesRepeat: [

                true ifTrue: [self yourself].

]]

 

57610

54798

46007

 

1 - (253154 / 46007) * -100.0

450.251

 

The relative difference is huge, but the cumulative cost is small enough to be ignored. Few would care about a cost like this, at least in VW. Be aware that there are object creation and disposal costs that are much higher in other dialects like GS/S. The relative difference is twice as bad on GS/S:

 

| t |

t := System timeNs.

10000000 timesRepeat: [[self yourself] if: true].

(System timeNs - t) // 1000.

 

3935243

3959995

3911631

 

| t |

t := System timeNs.

10000000 timesRepeat: [true ifTrue: [self yourself]].

(System timeNs - t) // 1000.

 

403045

401248

405734

 

1 - (3911631 / 401248) * -100.0

874.866

 

The complete avoidance of ComplexBlocks in GS/S for collection enumerations has commonly gained an 80% reduction in execution time in normal application code. That claim has met skepticism from even GemTalk development, but it is proven here by all our code. We use custom enumeration protocols to pass context as arguments into blocks so that they don't need to be copied with knowledge of outer context. The inefficiencies in kernel enumerations are tuned away, and because every execution is clean we are able to see significant application-level gains. It is not just that a ComplexBlock is used but how it is used that matters. It has to do with the cost of oop allocation and when the VM allows reclaim. ComplexBlocks used for enumeration have a higher hidden cost in GS/S than VW because garbage accumulates to affect performance.

 

Paul Baumann

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Wednesday, April 23, 2014 14:16
To: Steffen Märcker
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

 

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.

Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.

Randy

 

On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



 

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Niall Ross
Dear Randy,

>... most of the time I'll choose
>expressiveness over performance until my profiler tells me I have a problem.
>  
>
On the one hand, I'd agree with this in general:  I understand '"First
make it run, then make it right, last make it fast" to mean "Start by
writing expressively;  only rewrite code for performance after you've
solved the functional problem and only as needed".

However in this particular case, I'll now think out loud about how much
difference there is between the expressiveness of
    [process stop] if: process isRunning
and
    process isRunning ifTrue: [process stop].
by comparing the English forms of the two.
    [process stop] if: process isRunning
can be written as
    Stop the process if it is running
with no inversion of the 'if' relative to the 'is running'.   To avoid
inversion of 'process' and 'stop', you must use the vocative.
    O process, stop if you are running.
is how it would be written in a book of English grammar for exact
clarity, but of course
    Process, stop if you are running.
is valid English and so is
    Process, stop if running.
By contrast,
    process isRunning ifTrue: [process stop].
turns into
    Is the Process running?  If so, stop it.
or, vocatively,
    Process, are you running?  If so, stop.
or
    Process, are you running;  then stop.
This is close to
    If the process is running, stop it.
or
    If you are running, O Process, stop.
but these forms swap 'if' relative to 'is running' between the English
and the Smalltalk, so I guess the comparison is between
    Process, stop if you are running.
and
    Process, are you running;  then stop.

I notice that #if: and 'if' are textually closer than #ifTrue: and
'then' or indeed than #ifTrue: and 'If so'.
    process isRunning then: [process stop]
would be what I'd need for
    Process, are you running;  then stop.
to match the transliteration of
    [process stop] if: process isRunning
into
    Process, stop if you are running.
or alternatively, I'd need to write
    Process, are you running?  If true, stop.
(i.e. not 'If so, stop') which is correct but less colloquial English.  
(#ifTrue:ifFalse: could be #then:else: - I've a vague notion David
Simmons' dialect included that as an alternative syntax / presentation
format.)

My take:
    Process, stop if you are running.
has a very slight claim to smoother flow, while
    Process, are you running;  then stop.
shows that the command is only conditional slightly earlier than the
other, so has a very slight claim to being less open in hasty reading to
being misguessed then reassessed as it is read.

My conclusion:  the difference on either side seems so slight that I
would choose the more standard and significantly more performant form
every time.  By all means post in this thread re:

    - Does my view just mean I'm now very used to Smalltalk's style?

    - Does thinking the opposite just mean you are very used to reading
code under the influence of other coding language styles (i.e. as
against someone who knew English and was coming fresh to coding languages)?

    - Is it that the difference is usually slight, but there specific
cases where the difference in clarity between the two forms is not so
slight?

             Yours faithfully
                   Niall Ross
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Steven Kelly
Re: [vwnc] [ANN] SuffixConditionals
Interesting thoughts from Niall. I think part of the problem here is that Smalltalk often "talks to objects" in the second person when giving commands: "process stop!", but in conditionals it talks to them in the third person: "process isRunning?" (not "process areYouRunning?"). If our conditionals used a person-independent form, which works in direct speech to a second person: "running?", it might be easier to map Smalltalk and English. We could have something like:
 
process if: #running then: #stop.
 
where #if:then: would take two Symbols or Blocks with the receiver as an optional argument:
 
Object>>if: conditionValuable then: actionValuable
   ^(conditionValuable cull: self)
       ifTrue: [actionValuable cull: self]
 
I wonder how often the receiver of the condition is also the receiver of the action? My guess is this might be something of an anti-pattern: if it's the receiver in both cases, that means the current object is handling things on behalf of that receiver, rather than letting the receiver handle its own business. Better would be "process stopIfRunning", which leaves the implementation up to the receiver.
 
Since this thread was about SuffixConditionals, and my above example is backwards for them, how could it be turned around? "#stop if: process is: #running" is horrid in many ways. So maybe we just need to be polite:
 
process please: #stop if: #running.
 
:)
Steve


From: [hidden email] on behalf of Niall Ross
Sent: Sat 26/04/2014 19:28
To: Randy Coulman
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

Dear Randy,

>... most of the time I'll choose
>expressiveness over performance until my profiler tells me I have a problem.

>
On the one hand, I'd agree with this in general:  I understand '"First
make it run, then make it right, last make it fast" to mean "Start by
writing expressively;  only rewrite code for performance after you've
solved the functional problem and only as needed".

However in this particular case, I'll now think out loud about how much
difference there is between the expressiveness of
    [process stop] if: process isRunning
and
    process isRunning ifTrue: [process stop].
by comparing the English forms of the two.
    [process stop] if: process isRunning
can be written as
    Stop the process if it is running
with no inversion of the 'if' relative to the 'is running'.   To avoid
inversion of 'process' and 'stop', you must use the vocative.
    O process, stop if you are running.
is how it would be written in a book of English grammar for exact
clarity, but of course
    Process, stop if you are running.
is valid English and so is
    Process, stop if running.
By contrast,
    process isRunning ifTrue: [process stop].
turns into
    Is the Process running?  If so, stop it.
or, vocatively,
    Process, are you running?  If so, stop.
or
    Process, are you running;  then stop.
This is close to
    If the process is running, stop it.
or
    If you are running, O Process, stop.
but these forms swap 'if' relative to 'is running' between the English
and the Smalltalk, so I guess the comparison is between
    Process, stop if you are running.
and
    Process, are you running;  then stop.

I notice that #if: and 'if' are textually closer than #ifTrue: and
'then' or indeed than #ifTrue: and 'If so'.
    process isRunning then: [process stop]
would be what I'd need for
    Process, are you running;  then stop.
to match the transliteration of
    [process stop] if: process isRunning
into
    Process, stop if you are running.
or alternatively, I'd need to write
    Process, are you running?  If true, stop.
(i.e. not 'If so, stop') which is correct but less colloquial English. 
(#ifTrue:ifFalse: could be #then:else: - I've a vague notion David
Simmons' dialect included that as an alternative syntax / presentation
format.)

My take:
    Process, stop if you are running.
has a very slight claim to smoother flow, while
    Process, are you running;  then stop.
shows that the command is only conditional slightly earlier than the
other, so has a very slight claim to being less open in hasty reading to
being misguessed then reassessed as it is read.

My conclusion:  the difference on either side seems so slight that I
would choose the more standard and significantly more performant form
every time.  By all means post in this thread re:

    - Does my view just mean I'm now very used to Smalltalk's style?

    - Does thinking the opposite just mean you are very used to reading
code under the influence of other coding language styles (i.e. as
against someone who knew English and was coming fresh to coding languages)?

    - Is it that the difference is usually slight, but there specific
cases where the difference in clarity between the two forms is not so
slight?

             Yours faithfully
                   Niall Ross
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Randy Coulman
Interesting thoughts.  I hadn't really looked at which version was more English-like.  My thinking is more along the lines of, "Do I want to emphasize the action or the conditional in this expression?"  My answer changes depending on the circumstance.

I haven't codified when I prefer one over the other in my head yet; I need to play with it more to see when I'll use which form.  At best, the general thought I have in my head is that, if the action is going to be performed almost every time, then I'd lean toward the suffix form.

Either way, I wanted to have the option of choosing available to me, so I wrote the library and decided to share it.

Randy



On Sat, Apr 26, 2014 at 10:10 AM, Steven Kelly <[hidden email]> wrote:
Interesting thoughts from Niall. I think part of the problem here is that Smalltalk often "talks to objects" in the second person when giving commands: "process stop!", but in conditionals it talks to them in the third person: "process isRunning?" (not "process areYouRunning?"). If our conditionals used a person-independent form, which works in direct speech to a second person: "running?", it might be easier to map Smalltalk and English. We could have something like:
 
process if: #running then: #stop.
 
where #if:then: would take two Symbols or Blocks with the receiver as an optional argument:
 
Object>>if: conditionValuable then: actionValuable
   ^(conditionValuable cull: self)
       ifTrue: [actionValuable cull: self]
 
I wonder how often the receiver of the condition is also the receiver of the action? My guess is this might be something of an anti-pattern: if it's the receiver in both cases, that means the current object is handling things on behalf of that receiver, rather than letting the receiver handle its own business. Better would be "process stopIfRunning", which leaves the implementation up to the receiver.
 
Since this thread was about SuffixConditionals, and my above example is backwards for them, how could it be turned around? "#stop if: process is: #running" is horrid in many ways. So maybe we just need to be polite:
 
process please: #stop if: #running.
 
:)
Steve


From: [hidden email] on behalf of Niall Ross
Sent: Sat 26/04/2014 19:28
To: Randy Coulman

Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

Dear Randy,

>... most of the time I'll choose
>expressiveness over performance until my profiler tells me I have a problem.

>
On the one hand, I'd agree with this in general:  I understand '"First
make it run, then make it right, last make it fast" to mean "Start by
writing expressively;  only rewrite code for performance after you've
solved the functional problem and only as needed".

However in this particular case, I'll now think out loud about how much
difference there is between the expressiveness of
    [process stop] if: process isRunning
and
    process isRunning ifTrue: [process stop].
by comparing the English forms of the two.
    [process stop] if: process isRunning
can be written as
    Stop the process if it is running
with no inversion of the 'if' relative to the 'is running'.   To avoid
inversion of 'process' and 'stop', you must use the vocative.
    O process, stop if you are running.
is how it would be written in a book of English grammar for exact
clarity, but of course
    Process, stop if you are running.
is valid English and so is
    Process, stop if running.
By contrast,
    process isRunning ifTrue: [process stop].
turns into
    Is the Process running?  If so, stop it.
or, vocatively,
    Process, are you running?  If so, stop.
or
    Process, are you running;  then stop.
This is close to
    If the process is running, stop it.
or
    If you are running, O Process, stop.
but these forms swap 'if' relative to 'is running' between the English
and the Smalltalk, so I guess the comparison is between
    Process, stop if you are running.
and
    Process, are you running;  then stop.

I notice that #if: and 'if' are textually closer than #ifTrue: and
'then' or indeed than #ifTrue: and 'If so'.
    process isRunning then: [process stop]
would be what I'd need for
    Process, are you running;  then stop.
to match the transliteration of
    [process stop] if: process isRunning
into
    Process, stop if you are running.
or alternatively, I'd need to write
    Process, are you running?  If true, stop.
(i.e. not 'If so, stop') which is correct but less colloquial English. 
(#ifTrue:ifFalse: could be #then:else: - I've a vague notion David
Simmons' dialect included that as an alternative syntax / presentation
format.)

My take:
    Process, stop if you are running.
has a very slight claim to smoother flow, while
    Process, are you running;  then stop.
shows that the command is only conditional slightly earlier than the
other, so has a very slight claim to being less open in hasty reading to
being misguessed then reassessed as it is read.

My conclusion:  the difference on either side seems so slight that I
would choose the more standard and significantly more performant form
every time.  By all means post in this thread re:

    - Does my view just mean I'm now very used to Smalltalk's style?

    - Does thinking the opposite just mean you are very used to reading
code under the influence of other coding language styles (i.e. as
against someone who knew English and was coming fresh to coding languages)?

    - Is it that the difference is usually slight, but there specific
cases where the difference in clarity between the two forms is not so
slight?

             Yours faithfully
                   Niall Ross
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals

Antony Blakey-5
I hope to see a lot more of this kind of thinking/work. I certainly intend to do some, hopefully in a supported context. Even involving some small syntax changes (100% backwards compatible) that make it a lot easier.

On 27 Apr 2014, at 7:30, Randy Coulman <[hidden email]> wrote:

> My thinking is more along the lines of, "Do I want to emphasize the action or the conditional in this expression?"

+1

> if the action is going to be performed almost every time, then I'd lean toward the suffix form.

+1

Antony Blakey
--------------------------
Ph: +61 438 840 787

The difference between ordinary and extraordinary is that little extra.




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals - optimized

Steffen Märcker
In reply to this post by Randy Coulman
Hi Paul and Randy!

Performance shouldn't be a downside anymore. Yesterday I published[*] a branch (optimized) adding compiler optimization to SuffixConditionals. They're as efficient as #ifTrue:ifFalse: now. =)

Although the extension works well, I am not sure what's the cleanest approach to (unit) test the it. For now, there's only one test checking whether the optimization macros have been successfully registered. But ideally, the tests should check that
a) the non-optimized message sends work correctly
b) the optimized code works correctly
c) the optimization is actually applied
What do you think? Maybe you could even provide some test.

Kind regards,
Steffen

[*] Actually, I accidentally published two time in a row. Sorry, I marked SuffixConditionals 3 for deletion now.


Am 25.04.2014, 20:40 Uhr, schrieb Randy Coulman <[hidden email]>:

Hi, Paul,

Yeah, I recognize the performance hit over the standard #ifTrue:/#ifFalse: - even mentioned it in the package comment and Readme.  I wouldn't use this in performance-critical places, but most of the time I'll choose expressiveness over performance until my profiler tells me I have a problem.

You are, of course, free to choose otherwise :-).

Randy



On Fri, Apr 25, 2014 at 8:13 AM, Paul Baumann <[hidden email]> wrote:

It is nice, but I wouldn't use it unless it was compiler-optimized to be as efficient as #ifTrue:.

 

Be aware that debugging through this will be different. Be aware that there is a performance difference between the two approaches. The #ifTrue: is optimized by the compiler while the #if: pattern would often be a BlockClosure that maintains outer context.

 

Time microsecondsToRun: [10000000 timesRepeat: [

                [self yourself] if: true.

]]

 

256068

257670

253154

 

Time microsecondsToRun: [10000000 timesRepeat: [

                true ifTrue: [self yourself].

]]

 

57610

54798

46007

 

1 - (253154 / 46007) * -100.0

450.251

 

The relative difference is huge, but the cumulative cost is small enough to be ignored. Few would care about a cost like this, at least in VW. Be aware that there are object creation and disposal costs that are much higher in other dialects like GS/S. The relative difference is twice as bad on GS/S:

 

| t |

t := System timeNs.

10000000 timesRepeat: [[self yourself] if: true].

(System timeNs - t) // 1000.

 

3935243

3959995

3911631

 

| t |

t := System timeNs.

10000000 timesRepeat: [true ifTrue: [self yourself]].

(System timeNs - t) // 1000.

 

403045

401248

405734

 

1 - (3911631 / 401248) * -100.0

874.866

 

The complete avoidance of ComplexBlocks in GS/S for collection enumerations has commonly gained an 80% reduction in execution time in normal application code. That claim has met skepticism from even GemTalk development, but it is proven here by all our code. We use custom enumeration protocols to pass context as arguments into blocks so that they don't need to be copied with knowledge of outer context. The inefficiencies in kernel enumerations are tuned away, and because every execution is clean we are able to see significant application-level gains. It is not just that a ComplexBlock is used but how it is used that matters. It has to do with the cost of oop allocation and when the VM allows reclaim. ComplexBlocks used for enumeration have a higher hidden cost in GS/S than VW because garbage accumulates to affect performance.

 

Paul Baumann

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Wednesday, April 23, 2014 14:16
To: Steffen Märcker
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

 

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.

Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.

Randy

 

On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



 

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals - optimized

Paul Baumann

Nice work Steffen. I'm still not sure I'd use #if: for portability reasons, but perhaps it is something that would grow on me. The (<boolean> ifTrue: <action>) pattern seems like an easier sequence to follow than (<action> if: <boolean>) for the same reason that #on:do: is easier to read than the old #handle:do: exception handlers.

 

Paul Baumann

 

 

From: Steffen Märcker [mailto:[hidden email]]
Sent: Tuesday, April 29, 2014 03:35
To: Paul Baumann; Randy Coulman
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals - optimized

 

Hi Paul and Randy!

 

Performance shouldn't be a downside anymore. Yesterday I published[*] a branch (optimized) adding compiler optimization to SuffixConditionals. They're as efficient as #ifTrue:ifFalse: now. =)

 

Although the extension works well, I am not sure what's the cleanest approach to (unit) test the it. For now, there's only one test checking whether the optimization macros have been successfully registered. But ideally, the tests should check that

a) the non-optimized message sends work correctly

b) the optimized code works correctly

c) the optimization is actually applied

What do you think? Maybe you could even provide some test.

 

Kind regards,

Steffen

 

[*] Actually, I accidentally published two time in a row. Sorry, I marked SuffixConditionals 3 for deletion now.

 

 

Am 25.04.2014, 20:40 Uhr, schrieb Randy Coulman <[hidden email]>:

 

Hi, Paul,

 

Yeah, I recognize the performance hit over the standard #ifTrue:/#ifFalse: - even mentioned it in the package comment and Readme.  I wouldn't use this in performance-critical places, but most of the time I'll choose expressiveness over performance until my profiler tells me I have a problem.

 

You are, of course, free to choose otherwise :-).

 

Randy

 

 

On Fri, Apr 25, 2014 at 8:13 AM, Paul Baumann <[hidden email]> wrote:

It is nice, but I wouldn't use it unless it was compiler-optimized to be as efficient as #ifTrue:.

 

Be aware that debugging through this will be different. Be aware that there is a performance difference between the two approaches. The #ifTrue: is optimized by the compiler while the #if: pattern would often be a BlockClosure that maintains outer context.

 

Time microsecondsToRun: [10000000 timesRepeat: [

                [self yourself] if: true.

]]

 

256068

257670

253154

 

Time microsecondsToRun: [10000000 timesRepeat: [

                true ifTrue: [self yourself].

]]

 

57610

54798

46007

 

1 - (253154 / 46007) * -100.0

450.251

 

The relative difference is huge, but the cumulative cost is small enough to be ignored. Few would care about a cost like this, at least in VW. Be aware that there are object creation and disposal costs that are much higher in other dialects like GS/S. The relative difference is twice as bad on GS/S:

 

| t |

t := System timeNs.

10000000 timesRepeat: [[self yourself] if: true].

(System timeNs - t) // 1000.

 

3935243

3959995

3911631

 

| t |

t := System timeNs.

10000000 timesRepeat: [true ifTrue: [self yourself]].

(System timeNs - t) // 1000.

 

403045

401248

405734

 

1 - (3911631 / 401248) * -100.0

874.866

 

The complete avoidance of ComplexBlocks in GS/S for collection enumerations has commonly gained an 80% reduction in execution time in normal application code. That claim has met skepticism from even GemTalk development, but it is proven here by all our code. We use custom enumeration protocols to pass context as arguments into blocks so that they don't need to be copied with knowledge of outer context. The inefficiencies in kernel enumerations are tuned away, and because every execution is clean we are able to see significant application-level gains. It is not just that a ComplexBlock is used but how it is used that matters. It has to do with the cost of oop allocation and when the VM allows reclaim. ComplexBlocks used for enumeration have a higher hidden cost in GS/S than VW because garbage accumulates to affect performance.

 

Paul Baumann

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Wednesday, April 23, 2014 14:16
To: Steffen Märcker
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

 

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.

Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.

Randy

 

On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<<a href="http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public&#43;Store&#43;Repository" target="_blank">http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



 

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



 

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman





This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals - optimized

Randy Coulman
In reply to this post by Steffen Märcker
Hi, Steffen,

That's awesome!  I didn't even know those optimizations were done in the image; I thought they were in the VM, so I didn't even go looking.

When I get a chance, I'll review your changes and incorporate them.

Thanks for your contributions, I really appreciate the help.

Randy


On Tue, Apr 29, 2014 at 12:34 AM, Steffen Märcker <[hidden email]> wrote:
Hi Paul and Randy!

Performance shouldn't be a downside anymore. Yesterday I published[*] a branch (optimized) adding compiler optimization to SuffixConditionals. They're as efficient as #ifTrue:ifFalse: now. =)

Although the extension works well, I am not sure what's the cleanest approach to (unit) test the it. For now, there's only one test checking whether the optimization macros have been successfully registered. But ideally, the tests should check that
a) the non-optimized message sends work correctly
b) the optimized code works correctly
c) the optimization is actually applied
What do you think? Maybe you could even provide some test.

Kind regards,
Steffen

[*] Actually, I accidentally published two time in a row. Sorry, I marked SuffixConditionals 3 for deletion now.


Am 25.04.2014, 20:40 Uhr, schrieb Randy Coulman <[hidden email]>:

Hi, Paul,

Yeah, I recognize the performance hit over the standard #ifTrue:/#ifFalse: - even mentioned it in the package comment and Readme.  I wouldn't use this in performance-critical places, but most of the time I'll choose expressiveness over performance until my profiler tells me I have a problem.

You are, of course, free to choose otherwise :-).

Randy



On Fri, Apr 25, 2014 at 8:13 AM, Paul Baumann <[hidden email]> wrote:

It is nice, but I wouldn't use it unless it was compiler-optimized to be as efficient as #ifTrue:.

 

Be aware that debugging through this will be different. Be aware that there is a performance difference between the two approaches. The #ifTrue: is optimized by the compiler while the #if: pattern would often be a BlockClosure that maintains outer context.

 

Time microsecondsToRun: [10000000 timesRepeat: [

                [self yourself] if: true.

]]

 

256068

257670

253154

 

Time microsecondsToRun: [10000000 timesRepeat: [

                true ifTrue: [self yourself].

]]

 

57610

54798

46007

 

1 - (253154 / 46007) * -100.0

450.251

 

The relative difference is huge, but the cumulative cost is small enough to be ignored. Few would care about a cost like this, at least in VW. Be aware that there are object creation and disposal costs that are much higher in other dialects like GS/S. The relative difference is twice as bad on GS/S:

 

| t |

t := System timeNs.

10000000 timesRepeat: [[self yourself] if: true].

(System timeNs - t) // 1000.

 

3935243

3959995

3911631

 

| t |

t := System timeNs.

10000000 timesRepeat: [true ifTrue: [self yourself]].

(System timeNs - t) // 1000.

 

403045

401248

405734

 

1 - (3911631 / 401248) * -100.0

874.866

 

The complete avoidance of ComplexBlocks in GS/S for collection enumerations has commonly gained an 80% reduction in execution time in normal application code. That claim has met skepticism from even GemTalk development, but it is proven here by all our code. We use custom enumeration protocols to pass context as arguments into blocks so that they don't need to be copied with knowledge of outer context. The inefficiencies in kernel enumerations are tuned away, and because every execution is clean we are able to see significant application-level gains. It is not just that a ComplexBlock is used but how it is used that matters. It has to do with the cost of oop allocation and when the VM allows reclaim. ComplexBlocks used for enumeration have a higher hidden cost in GS/S than VW because garbage accumulates to affect performance.

 

Paul Baumann

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Wednesday, April 23, 2014 14:16
To: Steffen Märcker
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals

 

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!

That said, I would rather not include this extension. I think it’s less readable than the standard:

n odd ifTrue: [#odd] ifFalse: [#even]

In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.

Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?

I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.

My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.

Randy

 

On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



 

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman      GitHub: randycoulman



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman






--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] SuffixConditionals - optimized

Stéphane Ducasse
In reply to this post by Paul Baumann

On 29 Apr 2014, at 20:36, Paul Baumann <[hidden email]> wrote:

Nice work Steffen. I'm still not sure I'd use #if: for portability reasons, but perhaps it is something that would grow on me. The (<boolean> ifTrue: <action>) pattern seems like an easier sequence to follow than (<action> if: <boolean>) for the same reason that #on:do: is easier to read than the old #handle:do: exception handlers.

I agree.
As a guy that is writing books and teaching beginners I prefer not to have different forms and duplicated version of the same basic behavior. 
I think that if everybody start to add methods because he can we will have a mess. 
I do not see the added value of if: 

if we look at Squeak and Pharo, I think that dynamic arrays were a good addition, may be traits (and as author of traits I have a love hate relationships with them), If there is a change to introduce with real benefits it would be first class instance variables. This is something we added in Pharo in the machinery and 
soon in the public language api. 

Stef
 
Paul Baumann
 
 
From: Steffen Märcker [[hidden email]] 
Sent: Tuesday, April 29, 2014 03:35
To: Paul Baumann; Randy Coulman
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals - optimized
 
Hi Paul and Randy!
 
Performance shouldn't be a downside anymore. Yesterday I published[*] a branch (optimized) adding compiler optimization to SuffixConditionals. They're as efficient as #ifTrue:ifFalse: now. =)
 
Although the extension works well, I am not sure what's the cleanest approach to (unit) test the it. For now, there's only one test checking whether the optimization macros have been successfully registered. But ideally, the tests should check that
a) the non-optimized message sends work correctly
b) the optimized code works correctly
c) the optimization is actually applied
What do you think? Maybe you could even provide some test.
 
Kind regards,
Steffen
 
[*] Actually, I accidentally published two time in a row. Sorry, I marked SuffixConditionals 3 for deletion now.
 
 
Am 25.04.2014, 20:40 Uhr, schrieb Randy Coulman <[hidden email]>:
 
Hi, Paul,
 
Yeah, I recognize the performance hit over the standard #ifTrue:/#ifFalse: - even mentioned it in the package comment and Readme.  I wouldn't use this in performance-critical places, but most of the time I'll choose expressiveness over performance until my profiler tells me I have a problem.
 
You are, of course, free to choose otherwise :-).
 
Randy
 

 

On Fri, Apr 25, 2014 at 8:13 AM, Paul Baumann <[hidden email]> wrote:
It is nice, but I wouldn't use it unless it was compiler-optimized to be as efficient as #ifTrue:.
 
Be aware that debugging through this will be different. Be aware that there is a performance difference between the two approaches. The #ifTrue: is optimized by the compiler while the #if: pattern would often be a BlockClosure that maintains outer context.
 
Time microsecondsToRun: [10000000 timesRepeat: [
                [self yourself] if: true.
]]
 
256068
257670
253154
 
Time microsecondsToRun: [10000000 timesRepeat: [
                true ifTrue: [self yourself].
]]
 
57610
54798
46007
 
1 - (253154 / 46007) * -100.0
450.251
 
The relative difference is huge, but the cumulative cost is small enough to be ignored. Few would care about a cost like this, at least in VW. Be aware that there are object creation and disposal costs that are much higher in other dialects like GS/S. The relative difference is twice as bad on GS/S:
 
| t |
t := System timeNs.
10000000 timesRepeat: [[self yourself] if: true].
(System timeNs - t) // 1000.
 
3935243
3959995
3911631
 
| t |
t := System timeNs.
10000000 timesRepeat: [true ifTrue: [self yourself]].
(System timeNs - t) // 1000.
 
403045
401248
405734
 
1 - (3911631 / 401248) * -100.0
874.866
 
The complete avoidance of ComplexBlocks in GS/S for collection enumerations has commonly gained an 80% reduction in execution time in normal application code. That claim has met skepticism from even GemTalk development, but it is proven here by all our code. We use custom enumeration protocols to pass context as arguments into blocks so that they don't need to be copied with knowledge of outer context. The inefficiencies in kernel enumerations are tuned away, and because every execution is clean we are able to see significant application-level gains. It is not just that a ComplexBlock is used but how it is used that matters. It has to do with the cost of oop allocation and when the VM allows reclaim. ComplexBlocks used for enumeration have a higher hidden cost in GS/S than VW because garbage accumulates to affect performance.
 
Paul Baumann
 
 
From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Wednesday, April 23, 2014 14:16
To: Steffen Märcker
Cc: VW NC
Subject: Re: [vwnc] [ANN] SuffixConditionals
 

Hi, Steffen,

I appreciate your interest and desire to contribute to this. That’s awesome!
That said, I would rather not include this extension. I think it’s less readable than the standard:
n odd ifTrue: [#odd] ifFalse: [#even]
In my mind, SuffixConditionals only make sense when the focus of a line of code should be on the action more than the condition. But with the #if:else: variant, there are two actions and they’re now separated by the condition.
Is there a case where you would find a suffix #if:else: more readable than the same thing with #ifTrue:ifFalse:?
I’m open to having my mind changed if others feel strongly about it, but my initial reaction is not to include it.
My other concern is that adding #if:else: will make someone want to add #unless:else:, and that’s just pure evil :-). Ruby has that variant, and I’ve only ever seen Rubyists rant against anyone who uses it.
Randy

 

On Wed, Apr 23, 2014 at 8:25 AM, Steffen Märcker <[hidden email]> wrote:

Hi Randy!

Neat stuff! I've added a Pythonic #if:else: message which I find handy as well.

  [#odd] if: (n odd) else: [#even]

Find the changes attached. If you don't have objections I'd like to push them to the repo later today. Agreed?

Regards,
Steffen

Am 22.04.2014, 16:27 Uhr, schrieb Randy Coulman <[hidden email]>:

I have just released
SuffixConditionals<https://github.com/randycoulman/SuffixConditionals>which
allows for Ruby-like suffix conditionals in Visualworks Smalltalk.

SuffixConditionals adds #if: and #unless methods to BlockClosure, allowing
you to write statements such as:

[process stop] if: process isRunning

and

[process start] unless: process isRunning

SuffixConditionals is available in the Cincom Public Store
Repository<http://www.cincomsmalltalk.com/CincomSmalltalkWiki/Public+Store+Repository>.
A snapshot of the current version is also on
GitHub<https://github.com/randycoulman/SuffixConditionals>
.

The full release announcement is on my blog, Courageous
Software<http://randycoulman.com/blog/2014/04/22/suffix-conditionals-in-smalltalk/>


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



 
-- 
Randy Coulman
Twitter: @randycoulman      GitHub: randycoulman
 

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


 
-- 
Randy Coulman
Twitter: @randycoulman      GitHub: randycoulman





This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc