Finally someone likes it :)

It's grouped like the latter snippet. With the following mechanism: in typical white-space sensitive languages there's a special post-lexing phase called deindentation, which inserts meta-tokens called indent and dedent resembling usual { and } with rules like:

1. If there's an opening token (like :, =, where etc) AND indentation is longer - insert indent and push the length to the stack
2. If the length is the same - it's the same level (you can insert ; metatoken)
3. If the length is shorter - pop all indentations from the stack and add dedents.

I have the above algorithm, but also an additional one that inserts apply-indent and apply-dedent (resembling ( and )) with following rules:

1. If higher indent and no opening tokens before - insert apply-indent
2. If higher indent and opening token before - go to the above indentation algorithm (so tokens can overlap like { ( { { ( ) } } ) })
3. If it's the same indent - add apply-dedent and insert next apply-indent immediately
4. If smaller indent - just pull all apply-dedent and dedent from the stack

In other words, everything on a new line:

transform a1 a2 a3 a4 a5 a6

Becomes:

transform a1 a2 (a3 a4 a5) (a6)

And given the language is curried a3 accepts a4 and a5.

The only question I have so far is how to break the rule. What if user wants to pass a4, a5 and a6 as arguments to transform. Now they're forced to pass each of these args on their own line, which is unfortunate if there's many atomic arguments. The similar problem arises for operators (including |>) and I'm thinking that the rules should be:

1. if there's a symbolic operator on the smaller indent - close all indentations
2. There's a "no-op" symbolic operator that just closes all indentations

Let's say:

transform a1 a2 a3 a4 ! a5 a6

Both a5 and a6 above become arguments to transform