[ANN] SuffixConditionals

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

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

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.

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

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