If I ask for functional-language-style macros in K...

# announcements

[nickk]

If I ask for functional-language-style macros in Kotlin (like LISP , Elixir etc), I would currently be out of luck, right?

[Nikky]

hass been a while since i last looked at LISP, but maybe look at kotlin's infix functions ?

[Nikky]

but macro's like copypasting code with variables inside.. such a thing does nto quite exist..
unless you want to go totally over the top and use kotlin scripting but then you compiel a little program for every function

[nickk]

I want to factor out repetitive code, without having to declare a ton of Interfaces. I am seeking for textual replacement of the macro body at the call site, along with any arguments.

[Nikky]

the best you can do is write a script to generate the ktlin code

[Nikky]

or interfaces and extension functions where not possible

[nickk]

Not sure if this is better than copy-paste, regarding maintenance. Because I would still have to locate and replace stuff if I want to make a change.

[nickk]

Here I see a relevant discussion: https://discuss.kotlinlang.org/t/compile-time-functions-macros/2097

[sergio250]

What about using an annotation processor + a code generator like KotlinPoet?

[nickk]

Does not feel like this would reduce complexity, but I will take a look at KotlinPoet.

(HOW do you insert the generated code in the middle of a hand-crafted Kotlin class?)

[sergio250]

Yeah, it’s still quite cumbersome. I think you can’t include your generated code inside already existent files but create new ones. I’m not sure that solves your problem, though

[nickk]

KotlinPoet is interesting, but it does not solve my issue.

A macro would add its body in the call site. In the discussion linked above, it is open whether they will eventually be added in the language.

[Dico]

You can try running the c preprocessor on your kotlin source before compilation?

[natpryce]

The closest in pure Kotlin is a generic inline function that is passed lambdas for where the body must vary for different types

[Nikky]

you could probably make a preprocessor that does pure text replacement yourself

[Nikky]

jut need to make sure to move all your code out of src.. or to remove those from sourceSets and create new sourceSets where you coy the output

[Dico]

Yeah, you need to copy the source to build directory with a task and then run your preprocessor

[nickk]

@natpryce Macros would essentially “turn-off” or postpone type checking, while a generic function will not. Hence the compiler will bite at me…

[natpryce]

Sure. That’s why you need to write a generic function and pass in the actions that must differ by type.

[natpryce]

Turning off typechecking is going against the grain of Kotlin, although you can do so when compiling for the JavaScript target by declaring variables as type “dyn”

[nickk]

Think like this: same statements, with same variable names of different type or belonging to different types. I want to avoid Interfaces, passing 5 arguments, etc

[nickk]

Macros are special. Also, Kotlin has the !! operator to force operating on optionals… This is against the Kotlin mentality, too. Isn’t it?

[natpryce]

I get what you want, but it’s not what Kotlin encourages.

[nickk]

I want macro-based metaprogramming in Kotlin 🙂

[natpryce]

Yes. It’s not good form to use the bang-bang operator except when you can prove the non-nullity and the type checker cannot for some reason. In our project we ban it outright and it’s never been a problem

[nickk]

Jetbrains has left the case for macros open: "While it is possible that macros will be added to Kotlin at some point, we don't have any plans to work on them in the short or medium term."

[Dico]

As far as I know, the reasoning behind not having macros is that it would make the tooling in the IDE extremely complex. Powerful tooling (inspections, etc) is one of the 3 fundamental design ideas behind Kotlin. I think they said compiler plugins are intended to exist as a compromise of sorts, though, all of this is my own wording, mind you.

[nickk]

Well, annotation processors seem more complex to me. But I am ignorant of the tool internals.

[gildor]

AP is not so complex for tooling, because after build or some sync step you have full access to generated code. It may be not so pleasant in terms of UX, but tooling just work in the same way as for manually written code
Personally I don't think that macroses will be available in Kotlin and I personally would be against this.
Compiler plugins way looks much better for me, because also planning to have tooling support out of the box. But compiler plugins are not public and require quite a lot of work

[Dico]

I would be against macros too