Hi Team, I am planning to write a post on Kotlin C...

# arrow-meta

[Sushobh]

Hi Team, I am planning to write a post on Kotlin Compiler plugin built with Arrow meta. I had a few questions.
1. Does Arrow meta operate on the output of the compiler frontend or the backend? i.e are we modifying the tree after frontend process is completed or the tree after backend IR is completed?
2. How much of an impact will the upcoming new Kotlin FIR have on the arrow meta api?
3. What advantages does arrow meta bring to the table over creating a compiler plugin directly without using it? I know this question requires a long summary so feel free to skip this question.
4. I have created a gradle plugin which downloads the arrow meta jar and adds it to the kotlin options of the consumer project. This is how I have been using my plugin. Is it a technically sound approach?
Thanks for your help.

[Alejandro Serrano Mena]

A few answers (which may be expanded by others)
1. you can hook at different phases, but it’s in fact possible to work on the front end, so you can change code before being further analyzed, look at the types, and so on
2. the plan is to update Meta when FIR becomes stable. However, since many of the classes exposed byMeta come from the compiler, the change might be quite big. Also, the FIR API is going to have more hooks, so you might be able to get away without Meta.
3. I find Meta already useful for simply setting the plug-in up, because you don’t need to tinker with all the registrars, and other internal stuff. On that of that, it has useful ways to specify what you want to work on; you could do it directly, but would cost you more time.
4. The preferred way is to use the Meta Gradle library. You can see an example in the Arrow analysis repo; you only need to build a small library which points to the main class of the plug-in, and the rest is taken care of

[Sushobh]

Great. I still would like more clarity on my first question though.

[Sushobh]

When we call module.transform, are we modifying the frotend ir or backend ir?

[raulraja]

if module is IrModuleFragment it's backend. All Ir classes are backend. Arrow meta removed the quotes we used to have to create declarations and we are currently adapting everything to FIR. more info here https://github.com/arrow-kt/arrow-meta/issues/1058#issuecomment-1294800486

@Sushobh if you would like a review of the post before publishing please ping me and I can let you know if anything is not accurate. Currently we are in flux in compiler plugins world without a stable api and changing compiler frontend

[raulraja]

Neither the old frontend nor the new FIR is as flexible as the IR backend. The IR backend lets you transform the entire tree before codegen. In contrast the frontend api does not currently give you a way to transform descriptors or FIR elements beyond new code genration, call checking but no in place tree mutations as in the backend.

[Sushobh]

@raulraja Sorry if this a dumb question , my understanding is that FIR is changing ( the backend IR will stay the same) but we can still transform code with IR backend. So why is meta moving towards the new FIR? Can we not stick with same implementation and keep changing the backend IR?

[raulraja]

meta's current api around IR backend transformation is more or less stable and so is the IR format for backend. That won't change. The issue is that the compiler does not have a stable compiler api and some times the actual types change also in the backend. Meta is moving forward as general metaprogramming framework and will have apis for both frontend (FIR) and IR backend that are higher level than the ones today.

When writing a compiler plugin just targeting the backend is not enough if your plugin needs to perform call checking, diagnostics and other things over the code beside transforming it. Meta's only notable change in the last years is that we have removed completely the Descriptor+PSI frontend we had for quotes and code generation in the frontend. We got rid of it because it woulc never integrate with the IDE and real time syntax highlighting. We are moving to do that kind of thing with FIR because the new FIR frontend work on IDEA in real time and allows cooperation with the compiler plugin.

[raulraja]

We are currently in the process of creating an AST that is generic enough to do metaprogramming in both frontend and backend and a unified typed DSL that can be used to do code generation in the frontend and transformations in the backend with the same syntax. From that we will expose a form of declaration and expression macros that satisfy most compiler plugins that simply transform trees.

[Sushobh]

@raulraja Thanks for all of the info.