I want to build a library that will require code g...

# arrow-meta

[dephinera]

I want to build a library that will require code generation based on a DSL that will be executed runtime. It seems that I can’t do that with KSP, as it doesn’t provide access to function bodies or expressions. So it seems that the next option is analysing the AST. Can I use meta for that? I saw that Arrow has a new website now, that doesn’t provide information about meta. I only need the information from the static analysis, I don’t plan on doing any IR modifications.

[Youssef Shoaib [MOD]]

You might instead wanna use kotlin scripting for the user to initialise the DSL, and then do the code generation with KSP normally.

If not, either use FIR (very unstable and experimental) or IR (less unstable, still no comparability guarantee, but it would require fully compiling the code once)

[dephinera]

The DSL would require the runtime classpath available. The idea is to use a DSL instead of annotations with MyType::class values.

[Youssef Shoaib [MOD]]

Maybe FIR could be good then, although I'm not entirely sure if you can generate sources and rerun the front-end. You might end up having to run the FIR on your own first, generate the sources, and then allow the real compilation to happen.

[Youssef Shoaib [MOD]]

With the old frontend this pattern was quite simply (you would provide an analysis extension which would tell the compiler to rerun the front-end with the new sources available) but the old frontend had a much worse user experience.

[dephinera]

Given the circumstances with the old and new compiler I guess I'll stick with KSP and annotations. Thanks!

[Youssef Shoaib [MOD]]

You could theoretically do something complicated with functions and classes:

//User code
@ConfiguresLibraryDsl
fun config(): Config<MyType, MyOtherType, Extras.Combine3<Extras.EnableFeature1, Extras.EnableFeature2For<ADifferentType>, Extras.CustomizeFeature3<SomeToggle>>> = TODO()

You can have some of the info in parameters, receivers, etc. Sealed classes/interfaces are really your friend here. The nice thing about this is that you can have it so that the config function is declared inside a class to associate it with a specific class.

Also, I can't remember if KSP would let you see the inferred return types of expression functions or not, but if it can, then you can have it be more DSL-y by having functions that produce a Config from the types you enable, and you'll hence get the ability to make a lot of convenience functions, which will make the user experience much better.

[Youssef Shoaib [MOD]]

If you provide more info about your intended DSL, I can help show you what the class declarations would look like. Even better if you have an open-source POC or something like that already.

[dephinera]

That's an interesting suggestion. I guess it is similar to what Dagger does with the java annotation processor.

[Youssef Shoaib [MOD]]

But even better because of type aliases, sealed classes/interfaces, and type inference (if KSP supports it)