What I like about parentheses (and I hate parentheses) is that it allows me to view/describe the intent of the code. When parens are not used, it is up to me (perhaps years later) to determine whether the original developer (sometimes me) understood (or not) the actual 'order of processing'.�� Parens - or another vehicle - should help me understand the intent (as would detailed comments) - so I can devise tests (oh yeah, are those available, too?) for the intent - even if it is just me in the debugger.

So, I'm for whatever helps me understand the intent of the code - even if there is some slick way to nest everything. I generally prefer breaking nested processes down into multiple steps. Benchmarking rarely shows significant performance differences, for me.

(and I've used parentheses 7 times in this one email!)�� :-)

Russ

On Wed, Jan 26, 2022 at 4:20 AM Kasper Osterbye <kasper.osterbye@gmail.com> wrote:

Cheers all

I have noticed that I often ends up with quite a number of nested expressions, for example:

(((json at: 'tree')
�� select: [ :e | (e at: 'type') = ��blob' ])
�� collect: [:e | Path from: (e at: 'path')])
�� select: [ :p | p segments last
�� in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ]

What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax?

My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like
json at: ��tree' ��
�� select: [ :e | ((e at: 'type') = 'blob��)]��
�� collect: [:e | Path from: (e at: 'path��)]��
�� select: [ :p | p segments last
�� in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ]

Basically, a send the right hand expression to the result of the left hand expression.

Has anyone ever tried this, or is it just one of the many small annoyances best left alone?

Best,

Kasper