buildfoundation / ketolang Goto Github PK

We already run tests of course, but would be nice to also build samples on CI to validate their correctness

Sample should be built targeting both JVM and Native platforms.

Should make code clearer and leave less ways to write same code to users.

No GOTO!

After multiple discussions with JetBrains people, I was explained that Kotlin compiler is getting rearchitectured, in particular IR (intermediate representation) is getting split into Frontend IR (FIR) and Backend IR parts.

Currently, Ketolang hooks into IrGenerationExtension.

Ketolang code analysis should be moved to FIR when FIR is stabilized (currently in Alpha):

• IntelliJ will be running FIR analysis via compiler and configured compiler plugins to validate code in IDE, which will automatically integrate Ketolang analysis into IntelliJ! (errors)
• New IR architecture is faster than current IR — JB claims 4x improvement, since it doesn't rely on complete type inference nor complete code DOM tree being prepared in many cases nor global map of PSI symbols to parsed resolutions
• FIR is the right place to analyze code and generate stubs of declarations, Backend IR is the right place to generate actual IR bodies

Ketolang code generation (if added) should be moved to Backend IR:

• This way it won't slow down IntelliJ by generating code during code analysis, only FIR is going to be run in IntelliJ
• Code generated in Backend IR or IrGenerationExtension is not available for IntelliJ within the same module, however FIR can generate declarations of the members while Backend IR can later inflate them with IR bodies.

See:

• https://github.com/JetBrains/kotlin/tree/master/docs/fir
• https://kotlinlang.org/docs/whatsnew17.html

JB contact for this: Dmitry Novozhilov @demiurg906

Hi.

First off, this seems like a great project, and I am looking forward to keeping track of it's development.

I was wondering, will this project support higher-order functions with receivers? This seems like it would be very useful for allowing for common types of Kotlin-style DSLs for being defined in Ketolang, is (in my opinion) one of the most distinctive features of Kotlin, and I believe is still compatible with the goals of Ketolang.

One issue I see with this is that in order to be useful, Kotolang would probably have to also support interfaces to allow for useful receivers for builder DSLs. But then again, maybe defining data classes in a "record of functions" manner would be sufficient, e.x.

data class BuilderScope(
    val add: (Int) -> Unit
)

fun sillyBuilder(handler: BuilderScope.() -> Unit): List<Int> {
    // Internal mutable var -- allowed in Ketolang
    var ints = listOf<Int>()
    val scope = BuilderScope { ints = listOf(it) + ints }
    scope.handler()
    return ints
}

val example = sillyBuilder {
    add(1)
    add(2)
    add(3)
}