duangsuse::Echo
关于 Literate Kotlin project 结构的设计。 Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。 LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样： project(1) : sourceSet(N)…
关于
关于从 (scope, sourceSet) 到文件路径的分配，统一是
a.b.c:1, a.b:0 找 a.b.c.somechild 这样的前缀 map 可以抽象成 PrefixMap<K, V> 然后在查找时线性地 Descending set + target.startsWith(this)，当然好一点的方法是用 trie 字典树，可能是没有最好。关于从 (scope, sourceSet) 到文件路径的分配，统一是
/src/$scope/$sourceSet/$pkgPath/mdName.$language，语言先只能是一种，默认是 Kotlin。简而言之，Lkt 的命令行工具就是在支持文章结构的前提下允许自动组织项目结构，利用诸如 package 这样的信息自动组织。
duangsuse::Echo
关于 Literate Kotlin project 结构的设计。 Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。 LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样： project(1) : sourceSet(N)…
从序列模式提取的角度看，
而
而
-Tgradle 指的 "gradle" 实际上是一种生成插件，我们可以用 interface 来规定一个插件要实现的东西。interface GenerateIntrinsic {
fun solvePath(src: CompileUnit): Path
fun generateProject(base: File)
}
data class CompileUnit(val scope: String, val sourceSet: String, val name: String) interface LiterateKtPlugin<CFG> {
val name: String
fun readConfig(entry: Feed<Line>): CFG
fun create(cfg: CFG, properties: Map<String, String>): GenerateIntrinsic
}从序列模式提取的角度看，
而
[...](file_reference) 的正则是复用的```xxx
package ...
``` 的解析器是复用的而
-Tgradle 指的 "gradle" 实际上是一种生成插件，我们可以用 interface 来规定一个插件要实现的东西。interface GeneratePlugin<CFG> {
fun readConfig(entry: Feed<Line>): CFG
fun solvePath(src: CompileUnit): Path
fun generateProject(base: File)
}
data class CompileUnit(val scope: String, val sourceSet: String, val name: String)其实这可以更 declarative，可比较麻烦，而且我不知道 -T abc 和 -Tabc 该怎么样用 Parser 库的形式一起支持、处理，那样势必得使用带副作用或 contextual 的 parser，虽然我已经写了一个，但那样真的很 dirty 不如不用。
但它可以工作
但我讨厌只能工作的东西
-Tabc | -T, abc 处理起来真是无聊至极，String 层面不好处理因为有 -Tabc 这种连词的情况、Char 层面也不好处理因为有 -T abc…… 而且实在没必要上 Char解决，会引起处理与 shell 不协调。难道这个流就这么难以施用抽象性高的解析器？
但我讨厌只能工作的东西
-Tabc | -T, abc 处理起来真是无聊至极，String 层面不好处理因为有 -Tabc 这种连词的情况、Char 层面也不好处理因为有 -T abc…… 而且实在没必要上 Char解决，会引起处理与 shell 不协调。难道这个流就这么难以施用抽象性高的解析器？
duangsuse::Echo
但它可以工作 但我讨厌只能工作的东西 -Tabc | -T, abc 处理起来真是无聊至极，String 层面不好处理因为有 -Tabc 这种连词的情况、Char 层面也不好处理因为有 -T abc…… 而且实在没必要上 Char解决，会引起处理与 shell 不协调。难道这个流就这么难以施用抽象性高的解析器？
准确的说 String 层面也可以处理，可我现在安排的 Parser 基本组合和输入流没有 mark/reset 的支持感觉不自在，而且一旦能够区分 -T 后面有没有配置的话，就得上 contextual 解析器了，实在是没必要。
Kotlin 官方都没有提供 Native 侧的 File API，KN 都这么久了还没官方接口
很多类还是得放 jvmMain 里写
这个项目 DOM TypeScript 侧还好，如果要手动处理 Markdown 部分的话感觉有点越俎代疱，最好还是找找 Markdown 的 DOM 库。
很多类还是得放 jvmMain 里写
这个项目 DOM TypeScript 侧还好，如果要手动处理 Markdown 部分的话感觉有点越俎代疱，最好还是找找 Markdown 的 DOM 库。
solvePath 是把
generateProject 是映射完项目文件后期再来依据之前提供的 CFG 生成 build.gradle 和 settings.gradle、gradle/wrapper/gradle-wrapper.properties 的
readCompileUnit 属于默认实现，依据之前的默认 pkg 取 scope, sourceset 什么的和 filter code
(main, kotlin, org.duangsuse.sample) 给映射到一个包的路径如 /src/main/kotlin/org/duangsuse/sample generateProject 是映射完项目文件后期再来依据之前提供的 CFG 生成 build.gradle 和 settings.gradle、gradle/wrapper/gradle-wrapper.properties 的
AbstractGenerateIntrinsicreadLinks 属于默认实现，取 README.md 的依赖链接
readCompileUnit 属于默认实现，依据之前的默认 pkg 取 scope, sourceset 什么的和 filter code