I’d rather introduce a new primitive into the language (😱) that provides for this kind of composition but without nesting of curly braces. We run into it all the time even without compose. Instead of:

fun foo() = logged { transactional { ... } } // (1)
Padding(color=my) { OtherWrapper { Component() } } // (2)

It would be preferable to be able to write:

fun foo() = logged <compose> transactional { ... } // (1)
Padding(color=my) <compose> OtherWrapper <compose> Component() // (2)

The trick is what

<compose>

sequence of characters is. It is extremely hard to find a syntactic form that is readable and understandable, looks nicely, and is not ambiguous with all the current and potential future extensions of Kotlin language. Ideas are welcome, use a thread please 🧵

Obvious ones (but probably conflict with the language): ->, > and =>

there may be a member

x

The only unambiguous one here is

=>

but it stylistically conflict with the rest of Kotlin and is not really obvious to the novice reader (

logged => transactional

WTF?)

Ah

function

could be an ordinary class with an

invoke

operator.

What if you used an infix instead of a language construct?

logged and transactional

btw, I'd like functions to be delegatable.

fun foo() by logged { transactional(::someFunc) }

you could go with the haskell bind operator:

>>=

IMO the less un-google-able symbols the better, if you ask me I would even say

extends

is better than

:

lol that double negative confused me

Indeed. A infix word there is more googlable and readable, but I don’t see how it can be done unless it is already a reserved word (it will produce too ambiguous grammar)

What about

using>

? It is the only unambiguous thing I can think that is abvious while reading

>

? it's already ambiguous in the existing language 🙂

From the looks of it I like

|>

the most, but the problem is that in JS it does completely different thing. It subsumes Kotlin’s scoping function

let

and Kotlin’s extensions in general:

5 |> increment // JS
5.increment() // Kt (1)
5.let(::increment) // Kt (2)

Could you explain a case in which using a non-keyword would be ambiguous?

btw, bug fixes are way greater than a possibility to write

func <smth> expr

instead of

func { expr }

What about a

\

?

I would read that either as

division

or

or

, so I don't think it's a very good candidate

@Fudge Assume you have an “infix” function

then

to write

Padding(color=my) then Component()

. But now it can be parsed as one-argument call to

Padding

, application of infix

then

with

Component

or a two-argument call to

Padding

with a second argument being lambda encapsulating

Compose()

. It is not just syntactically ambiguous, you’ll have to do call resolution twice (for one- and two- argument

Padding

) to see which one was meant here — this is something that should not be done.

I see, thanks @elizarov

I'll take bitwise operators over anything else :)

It's not like they don't exist, you can even make it one letter (like

a

) if It's too long

I really like

|>

and

>>=

ideas for that and I see what we want here like an opposite solution of Js / Elixir pipe operator (

() -> T

instead of

(T) -> Unit

), but it still have the same principle of

|>

from JS and Elixir then I don't see problems, in the end we have the same operator that compose things.

@Fudge They’re not too long, they’re hard to read

Also, because they are infix functions instead of operators, they don't follow the common precedence from other languages.

@bloder there is also a reverse pipe operator in F# called

<|

yeah I was looking for a implementation in some language and I thought in <| too lol, thank you

@elizarov just make a way to declare a precendence for infix functions and it should work

Thanks, but no. Other people had been there, done that. We know how it ends.

Yet you want to break precendence for a concrete usecase instead of making a generic solution ;)

One more thing to think about. If

func <operator> expr

desugars to

func { expr }

, it makes function boxing (anonymous class generation) even more implicit.

Could this cause ambiguity?

fun foo(op: () -> Unit): () -> Unit
fun bar(op: () -> Unit)
fun bar(): Unit
fun baz(): Unit

foo <...> bar <...> baz
// Is that equal to
foo { bar { baz() } }
// or
foo { bar() } { baz() }

Or am I just confusing myself?

Should be the first one unless you put brackets What does the second one even mean?

Yes. Design is always tradeoff. On one side you have implicit lambdas (boo - scary), on the other side deeply nested curly braces (ugly and verbose).

How deeply nested should we expect these braces to get, and is it really much of an issue? In TornadoFX, there's a fair amount of nesting for both the layout and CSS DSLs, and it hasn't really been an issue. If the nesting gets too severe, you just pull it out to a separate function.

Even a couple “wappers” like

padding

or

logged

start to use too much precious screen space and even more dear mental parsing capacity. My personal favorite is reverse pipe

<|

. It shows the direction of “embedding” and resembled an opening brace, but it is going to be tough for novices due to its utter unfamiliarity.

following this example should we have something like:

foo().bar().5

?

5

?

something like foo(bar(5))

It's specifically for components

oh I see, not a general solution to composition

I think Roman means something like this

Padding(color=my).around().Column {
   Text("Hello")
}

You don’t need

around

. Dot is enough in compose context.

So

Padding(color=my).Column {
   Text("Hello")
}

?

This solution can be generalized to some extent outside of compose, but functions will have to opt-in into this kind of use.

As much as I dislike them, I can sure see how Rust style macros would provide a sleek solution here.

Rust provides four types of macros 🙂

Fair enough 🙂

Why not just go with the Scala approach and include something like

infix fun andThen

into the stdlib? I’m not opposed to an operator syntax, but too many operators can obviously make code confusing.

fun pascalCase() = snakeCase andThen upperCase

That works when both left and right parameters to

andThen

are expressions whose type is a functional type like

(A) -> B

. Neigher

Padding(color=my)

nor

Component()

expressions in our discussion have such a type.

Oh, I misunderstood. Nevermind!

But for “function wrappers" like logged and transactional there is a solution along these lines (not mine invention, cannot remember where I’ve seen it)

that’s neat.

There's a shortcut: play.kotl.in There's also an old school version: try.kotl.in (much less mobile friendly, quite an IDE feel to it)

yeah the old school version was the one i knew about. this one feels nice 🙂