https://kotlinlang.org logo
Title
n

nickk

01/11/2019, 1:40 PM
If I ask for functional-language-style macros in Kotlin (like LISP , Elixir etc), I would currently be out of luck, right?
n

Nikky

01/11/2019, 1:42 PM
hass been a while since i last looked at LISP, but maybe look at kotlin's infix functions ?
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
n

nickk

01/11/2019, 1:45 PM
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.
n

Nikky

01/11/2019, 1:46 PM
the best you can do is write a script to generate the ktlin code
or interfaces and extension functions where not possible
n

nickk

01/11/2019, 1:47 PM
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.
s

sergio250

01/11/2019, 1:49 PM
What about using an annotation processor + a code generator like KotlinPoet?
n

nickk

01/11/2019, 1:52 PM
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?)
s

sergio250

01/11/2019, 1:54 PM
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
n

nickk

01/11/2019, 1:56 PM
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.
d

Dico

01/11/2019, 2:07 PM
You can try running the c preprocessor on your kotlin source before compilation?
n

natpryce

01/11/2019, 2:25 PM
The closest in pure Kotlin is a generic inline function that is passed lambdas for where the body must vary for different types
n

Nikky

01/11/2019, 2:42 PM
you could probably make a preprocessor that does pure text replacement yourself
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
d

Dico

01/11/2019, 2:48 PM
Yeah, you need to copy the source to build directory with a task and then run your preprocessor
n

nickk

01/11/2019, 2:48 PM
@natpryce Macros would essentially “turn-off” or postpone type checking, while a generic function will not. Hence the compiler will bite at me…
n

natpryce

01/11/2019, 2:59 PM
Sure. That’s why you need to write a generic function and pass in the actions that must differ by type.
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”
n

nickk

01/11/2019, 3:01 PM
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
Macros are special. Also, Kotlin has the !! operator to force operating on optionals… This is against the Kotlin mentality, too. Isn’t it?
n

natpryce

01/11/2019, 3:03 PM
I get what you want, but it’s not what Kotlin encourages.
n

nickk

01/11/2019, 3:03 PM
I want macro-based metaprogramming in Kotlin 🙂
n

natpryce

01/11/2019, 3:05 PM
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
n

nickk

01/11/2019, 3:07 PM
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."
d

Dico

01/11/2019, 3:23 PM
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.
n

nickk

01/11/2019, 3:27 PM
Well, annotation processors seem more complex to me. But I am ignorant of the tool internals.
g

gildor

01/13/2019, 1:53 AM
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
d

Dico

01/13/2019, 5:50 AM
I would be against macros too