I have a few questions if someone could assist: I ...

# arrow-meta

[dalexander]

I have a few questions if someone could assist:
I want to generate adapters between an internal representation of data and a data class so I can do something like DataClass.from(internalRepresentation) without requiring developers to hand write the from adapter. I would do this using annotation processing but there's data missing in the kapt Java stubs (default values). I want to eventually add some validation as well, but generating adapters is the first step.
1) How safe would Arrow Meta would be for doing this for production? ie. How likely are there to be breaking API changes (especially non-trivial ones). I know there's some compiler revision going on right now so there's potentially a lot of uncertainty.
2) Is it reasonable to want to use Arrow Meta/a compiler plugin to do this?
3) Is it possible to use Arrow Meta like an annotation processor to generate code/classes for this rather than interacting more directly with the compiler (the examples I see are focused on transformation rather than generation)? (Generated code would provide a better plan B in case the plugin breaks at some point). Nevermind this one, just found the answer (yes).

[raulraja]

Hi Derek,

1) How safe would Arrow Meta would be for doing this for production? ie. How likely are there to be breaking API changes (especially non-trivial ones). I know there’s some compiler revision going on right now so there’s potentially a lot of uncertainty.

Arrow meta from here on will follow compiler releases and will release the first stable version when the compiler makes the IR backend non-experimental which also others like Jetpack compose are waiting for. From that point forward as in any compiler plugin they are always tied to the compiler runtime so you also will have to release each time the compiler releases until they provide a public stable API.

2) Is it reasonable to want to use Arrow Meta/a compiler plugin to do this?

Yes, you can already use meta to access the precise typechecked info of a data class without the java stubs limitations you find in kapt and use meta to generate new sources or transform the IR tree before code generation.

[raulraja]

To the last question meta also plans to include inductive derivation in the proof system which covers your use case of deriving behaviors from structure

[raulraja]

All data classes have isomorphisms to tupleN in meta and we are working on derivation that is automatic. We already have semi automatic derivation working https://github.com/arrow-kt/arrow-meta/blob/master/compiler-plugin/src/test/kotlin/arrow/meta/plugins/proofs/ResolutionTests.kt#L224

[raulraja]

Feel free to get any of the code from there or the proof system that can help with your use case, we are still finishing it up and that is not production ready yet

[raulraja]

We are refactoring Arrow to use the proof system and we plan on removing the arrow-generic module in favor of automatic derivation with the arrow plugin

[dalexander]

Thanks you for the very detailed response! I think I'll give it a try and see what I can manage.

[dalexander]

I'm hoping to write a plugin that is more likely to be stable since only a subset of the team I'm on is likely to be interested in maintaining it, so probably going to try to avoid doing anything with IR since that seems to be under more active development.

[raulraja]

IR is the future of Kotlin if you don’t depend on IR then you have to provide ASM or similar for your plugin which is ment to be faded out, so that’s the other risk and why we are all waiting on IR

[dalexander]

Ah. It seems like it was possible to produce Kotlin source files, which shouldn't inherently be dependent upon the IR? I guess arrow meta is dependent on the IR for making calls to whatever plugin I write though.

[raulraja]

No, that is possible

[raulraja]

Arrow meta does not depend on IR if you are just gonna use to get sources in the quotes or analysis phase

[raulraja]

So yeah you can use meta as if it was kapt to gen sources