This is what I got with the PSI approach:

Hi folks! First of all, a few little disclaimers: I will try my best to react in a timely manner on your questions, but, unfortunately, I cannot guarantee that discussions won’t hang from time to time on my side (especially, initially, when I have to dive into the context). Also, just to be clear, I’m operating here completely out of my curiosity about your work and wish to help. All my advices and suggestions shouldn’t be treated as an official support from Kotlin Team, nor as an encouragement to write compiler plugins. Compiler API is still unstable, no guarantees are made about it, we are not responsible for any issues and poor UX with it, blah-blah-blah, you get it 🙂 Here, I’m just a guy who happens to know a bit how Kotlin Compiler works

And currently there are no plans on this changing, correct? It's poor UX for any user of any mpp library that includes any meta, no? I think has been asked already but it wasn't 100% clear to me if there was any ongoing discussion or plans to improve this. Also there is any (public) road map for plugins?

Someone in the channel mentioned that there is a way to Shadow the jar of the compiler plugin so the same sources can be used for the IDEA one and avoid two different modules. Is that something that makes sense or you'd recommend?

why I essentially want is an implicit type conversion which currently is workaround with a cast even though we have proof that OptionOf is only extended by Option

@dsavvinov @dmitriy.novozhilov in case any of you can help with the reason and alternatives. I’m getting this error when attempting to modify a Psi node in the `SyntenthicResolverExtensions.generateSyntheticClasses(PackageDescriptor...)`:

Caused by: java.util.MissingResourceException: Can't find bundle for base name messages.PsiBundle, locale en_GB
	at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1581)
	at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
	at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
	at org.jetbrains.kotlin.com.intellij.psi.PsiBundle.getBundle(PsiBundle.java:45)
	at org.jetbrains.kotlin.com.intellij.psi.PsiBundle.message(PsiBundle.java:33)
	at org.jetbrains.kotlin.com.intellij.psi.impl.CheckUtil.checkWritable(CheckUtil.java:47)
	at org.jetbrains.kotlin.com.intellij.extapi.psi.ASTDelegatePsiElement.replace(ASTDelegatePsiElement.java:371)

Seems like any calls to

replace

or

astReplace

in any psi element fails with similar errors. Is there a way with compiler plugins to modify the PsiElements to make adjustments and replacements before it goes into type checking and generation?

@dsavvinov @dmitriy.novozhilov or others that may know, I’m implementing the KEEP-87 as a compiler plugin to see if its possible in arrow meta. I’m attempting currently to get a hold of the resolver of the function injected with

@with

to enhance the scope resolution of that function so it takes in account the

Semigroup<A>

type to resolve

combine

without the need to wrap the body in

with (S) { a.combine(b) }

. What part of the compiler do I need to look into to avoid the

unresolved reference: combine

? In the actual Keep impl this happens in the

BodyResolver

but not sure how to get to that point in a compiler plugin. Any help or pointers in the right direction is appreciated.

Can a compiler plugin suppress or intercept the diagnostic for

NoValueForParameter

similar to how it was done in the KEEP https://github.com/arrow-kt/kotlin/pull/6/files#diff-792252e1fcae31609d7348297b7c45f4R46 ?

Thanks!

@dmitriy.novozhilov Do you know how I can get the import for org.jetbrains.kotlin.resolve.PlatformDependentAnalyzerServices. It is not in the kotlin-compiler-embeddable artefact

Or should we just go deeper in the resources meaning instead of

compile "org.jetbrains.kotlin:kotlin-compiler-embeddable:$kotlin_version"

we do:

api "org.jetbrains.kotlin:kotlin-compiler-embeddable:$kotlin_version"

I discussed this internally but thought I’d keep everyone in the loop here too: Here is a preliminary design of what enabling QuasiQuote support over a Compiler Descriptor may look like: https://github.com/47deg/arrow-meta-prototype/compare/rr-tree-quotes-poc#diff-109f0a910d70fe85c5eea3bc6dce4775 That is the basic algebra with an embedded function that exercises the steps it takes to transforms a string into a descriptor tree then back. Supporting then an individual descriptor like ValueParameters may look like this: https://github.com/47deg/arrow-meta-prototype/compare/rr-tree-quotes-poc#diff-21516eec047a3b472606f772e9accd8d Essentially if we implement this algebra for each Declaration Descriptor that there is out there matching the different KtElements and strategies to update or create under a parent then we can support quasiquotes in Kotlin in the

syntheticResolver

. Where users do something like:

func({
  "fun <$typeArgs> $name($params): $returnType = $body" //find
}) { fn ->
  "fun <$typeArgs> $name($params): $returnType = $body" //transform
}

In this case that would be the identity element for the

ValueParameter

declaration quote. This is in a similar way the quasiquote style syntax that scala-meta uses and much easier for most use cases to develop compiler plugins in comparison with the compiler internals, descriptor and phases we have to deal today. Say you had a use case to add logging to all functions named

foo

that return

Unit

. This will be the expression that satisfies that use case in a compiler plugin:

func({
  "fun <$typeArgs> foo($params): Unit = $body" //find
}) { fn ->
  "fun <$typeArgs> $name($params): $returnType { 
      println("inside foo: Unit")
      return $body" 
  }
}

implicit_cast_for_kinded_values_replaces___fix___.kt

The TC plugin automatically finds the factory that will be used as expression if found in the type class package, the data type package or in the local modules if flagged as

internal

Did you explore possible solutions for debugging generated code?

Hey, as a followup to my message above: If you are generating new files in the

build

folder (and mark them in gradle) instead of appending to already existing ones, debug seems to work out of the box I have implemented POC to entertain the idea - https://github.com/ShikaSD/kotlin-compiler-di/commit/b7c7f77f5b0b1436e7107421f21fcb6f1910cf88

In Addition to our current compiler plugins we’d like to present

autofold

, which will give you an automatic fold function over valid GADT/ ADT in vanilla Kotlin at compile time.

sealed class A

data class B(val x: Int) : A()
data class C(val x: Int) : A()
object D : A()

sealed class Expr<out A, B>
data class Const(val number: Double) : Expr<Nothing, Double>()
data class Sum<C>(val e1: Expr<Int, C>, val e2: Expr<Int, C>) : Expr<Int, C>()
object NotANumber : Expr<Nothing, Nothing>()

fun syntheticExprFold(): Int =
    Sum(
      e1 = Const(3.0),
      e2 = Const(2.1)
    ).fold(
      { c: Const -> c.number.toInt() },
      { _: Sum<Double> -> 0 },
      { 94 }
    )

fun syntheticAFold(): Int =
    B(44).fold(
      { b: B -> b.x * b.x },
      { c: C -> c.x - c.x },
      { 0 }
    )

Here is the code: https://github.com/47deg/arrow-meta-prototype/blob/master/compiler-plugin/src/main/kotlin/arrow/meta/autofold/AutoFoldPlugin.kt arrow

@raulraja Hey, I have seen you adding some extensions for PackageFragmentProvider. Did you find any use for those extensions in terms of providing additional files? I was trying to generate some synthetic descriptors using it, but failed miserably with lots of recursion errors.

More related progress, the type-class plugin is working in my local branch in both CLI and IDE augmenting function scopes

I have one question about the plugin, If I have a library that uses arrow-meta plugin, when an app uses my library, does it need to use arrow-meta as well?

Hey Raul, could you please help me to build and run your branch? I'd like to play around and maybe work on in later. Thanks!

Looking forward to meeting you there 🍻

@pakoito or anyone that can help rewriting some suspension so it works in IR…. We have an issue with Meta, the IR format and some of the stuff we have in the Arrow code base. Seems like IR is not complete even for JVM and does not support certain things we seem to use in Arrow. 1. Type aliases like Validated.Valid / Validated.Invalid declared in the same file that point to an inner class is one of them. This easy to resolve because those type aliases wouldn’t need to be there if Valid and Invalid weren’t nested. I got passed this issue refactoring Valid and Invalid to be top level. 2. suspended anonymous functions like this one fail to find their context:

fun <B> bindingFilter(c: suspend MonadFilterSyntax<F>.() -> B): Kind<F, B> {
    val continuation = MonadFilterContinuation<F, B>(this)
    val wrapReturn: suspend MonadFilterSyntax<F>.() -> Kind<F, B> = { just(c()) }
    wrapReturn.startCoroutine(continuation, continuation)
    return continuation.returnedMonad()
  }

In this function IR codegen freaks out with :

{ just(c()) }

getting into this error: https://github.com/JetBrains/kotlin/blob/9c9d2b5ad4ac27a0792d3cf4c62599fb3e09ebbb/compiler/ir/backend.jvm/src/org/jetbrains/kotlin/backend/jvm/lower/AddContinuationLowering.kt#L420 Seems like IR is unable to deal with suspended lambdas like this one. While I still have work in the comprehension plugin which will get rid of this problem all together I wonder if there is a way to rewrite that so that is not a suspended lambda.

May be a good first compiler contribution if someone is interested. My guess is that they don’t handle in the impl correctly the fact that the function is suspended and it runs into an NPE

@Imran/Malic cc @raulraja https://github.com/arrow-kt/arrow/pull/1713 is a wip pull request to add test support to the Arrow IntelliJ plugin. This will only be useful when the metadata generation has been implemented. Let me know if this proposal makes sense at all or if you have questions about it.

Hi guys. Wanted to play around meta plugin this weekend, but it looks like it’s archived on GH (https://github.com/arrow-kt/arrow-meta-prototype, from channel header). Any updated links to compile and test?

As an example if you want to write your own version of the typeclass- plugin you would start defining a costume HKT plugin before you start your implementation. Without HKT you will gain littel with Typeclasses.