Extend CS DSL support in compiler plugin #1079
Conversation
koperagen
added
the
Compiler plugin
koperagen
force-pushed
the
compiler-plugin-dev-2
branch
from
beb5c3e to
c5680dd
Compare
| @@ -61,3 +64,20 @@ public interface ColumnWithPath<out T> : DataColumn<T> { | |||
| } | |||
|
|
|||
| public val <T> ColumnWithPath<T>.depth: Int get() = path.depth() | |||
|
|
|||
| public fun ColumnWithPath(column: DataColumn<*>, path: ColumnPath): ColumnWithPath<*> = | |||
There was a problem hiding this comment.
Duplicate logic to BaseColumn<T>.addPath(path: ColumnPath). They should probably call each other if we want to keep both
There was a problem hiding this comment.
That's a good point, thank you. I'll call addPath from ColumnWithPath
|
Wow really cool! :D That's so many supported functions :) Does the compiler plugin need to understand the entire expression or can it also just understand a part of it? Like: df.select { name and cols { false } }.name |
| } | ||
|
|
||
| interface ColumnsResolver { | ||
| interface ColumnsResolver : org.jetbrains.kotlinx.dataframe.columns.ColumnSet<Any?> { |
There was a problem hiding this comment.
Why does this not inherit org.jetbrains.kotlinx.dataframe.columns.ColumnsResolver<Any?> like the name suggests? I suspect this is gonna be confusing in the future (oh it's because I sealed it... oops... oh well, just have to be careful with instance checks for when some columnsResolver is a singlecolumn or columnset)
There was a problem hiding this comment.
Hmm, yes, i picked this name before i dig into CS DSL. Now it's kind of a legacy mode for compatibility with previously implemented functions, that needs to be refactored. After that i'd rename ColumnResolver (plugin) -> ColumnSetApproximation, and remove ColumnResolver (plugin) from supertypes of SingleColumnApproximation . Sounds good?
There's no such partial evaluation in place now |
koperagen
force-pushed
the
compiler-plugin-dev-2
branch
from
c5680dd to
8497e3e
Compare
| } | ||
|
|
||
| @DataSchema | ||
| interface Person2 { |
There was a problem hiding this comment.
sometimes I suppose it's bad that some numerical types as Long/Double are not presented in this dataset
There was a problem hiding this comment.
true, I suppose weight could be a double actually, that's pretty realistic
| } | ||
| } | ||
|
|
||
| internal class AllAfter2 : AbstractInterpreter<ColumnsResolver>() { |
There was a problem hiding this comment.
What's the difference between AllAfter1/AllAfter2
There was a problem hiding this comment.
CS DSL functions differ a little, but plugin implementation happened to be the same. You're right, i'll update it to use abstract class
| val Arguments.receiver: ColumnsResolver by arg() | ||
| val Arguments.column: SingleColumnApproximation by arg() | ||
| override fun Arguments.interpret(): ColumnsResolver { | ||
| return columnsResolver { receiver.allBefore(column) } |
There was a problem hiding this comment.
Seems like it could be one class with the reference on function in some cases
There was a problem hiding this comment.
Would be cool! I tried to get the reference to allBefore, but it's strange.. Hard to get the reference to an extension function inside interface, plus we have ambiguity. So this doesn't compile
public companion object {
internal val AllColumnsSelectionDsl<*>.a: ColumnSelectionDsl<*>.(ColumnSelector<*, *>) -> ColumnSet<*> get() = ColumnsSelectionDsl<*>::allBefore
}
| } | ||
| private fun List<AnyCol>.mapBack(): List<SimpleCol> = map { it.asSimpleColumn() } | ||
|
|
||
| fun AnyCol.asSimpleColumn(): SimpleCol { |
There was a problem hiding this comment.
could you add some comment, when to use this function
| public fun <T> DataFrame<T>.xs(vararg keyValues: Any?): DataFrame<T> = | ||
| xs(*keyValues) { | ||
| colsAtAnyDepth { !it.isColumnGroup() }.take(keyValues.size) | ||
| } | ||
|
|
||
| @Refine |
There was a problem hiding this comment.
Could you please explain, when we are using @refine and when are not using this
There was a problem hiding this comment.
Refine is needed when fuction returns dataframe, datarow or groupby. It indicated that type parameter of the return type will be updated by the plugin. interpretable indicated more general situation for CS DSL for example, where plugin doesn't touch return type
I made adapter layer, so most implementations in compiler plugin just delegate to core. So most of this PR are tests for all different overloads, making sure they work