休息完了，虽然我还是那么菜，接下来的时间里，我会完成 LiterateKt 剩下的任务，以及编写 AXML 文件读写器、Kotlin 的 relational 库。
然后可以继续我的 ParserKt 『博客』编写，以及最后对绝句程序设计语言翻译器的实现。

关于 Literate Kotlin project 结构的设计。

Literate Kotlin 之前基于 literateBegin..literateEnd 且允许单层嵌套的设计，已经在 TypeScript 语言里作为小脚本完成实现，单独的命令行工具也会采用这样的单 markdown 结构。

LiterateKotlin 目前为了实用，先是按向 Gradle project 生成设计的，我们认为，Gradle 的 dependencies 是这样：

project(1) : sourceSet(N)
sourceSet(1): scope(1)-dependency(1)

比如下面这样：

sourceSets {
commonMain {
dependencies { implementation kotlin('stdlib-common') } }
/**/

而 GitHub 以及一般的规范是用 README.md，所以，项目的 entry file 算是 README 文件。

## Literate Kotlin

`g:v:n`

+ [...](r1)
+ [...](r2)
+ ...

### Build Dependencies

```kotlin
package apples // (main, java)
package somepkg // (scope, sourceSet)
//...
```

+ `depkind something` (main, java)
+ ...



### Build Script 

> [settings.gradle](settings.gradle)

```xxx
//code here
```

每个单独的引用项目也应该有一个

## Literate Kotlin

+ [...](file_reference)
+ [...](file_reference)
+ ...

而单独的 markdown 文件开头（第一个 <h1> 后，任何非 <h1> heading 前）则应该有

```xxx
package ...
```

来指定这个文件归属的位置，可以像上文 README 里那样带 // (scope, sourceSet)，如没默认按之前 README 的 map 起始部分来认。

然后命令行很简单

kotlinlit -Tgradle -t gradleVersion=4.1 -d build -s .

关于 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 这样的信息自动组织。

从序列模式提取的角度看，

而 -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)

有点累……

烦死了，到底该不该有

看起来用这种方式实现 -T, abc 和 -Tabc 一起解析是个错误的决定

强烈建议使用传统方式解析

……简直就是噩梦…… 如果用户输入重了，怎么办？毫无提示？ 难道就这样就没有更好的方法了？

其实这可以更 declarative，可比较麻烦，而且我不知道 -T abc 和 -Tabc 该怎么样用 Parser 库的形式一起支持、处理，那样势必得使用带副作用或 contextual 的 parser，虽然我已经写了一个，但那样真的很 dirty 不如不用。

真是太愚蠢了，我连既能 match 又能 format 的东西都写不出来…… 而且 parser 写得还那么不好看

但它可以工作
但我讨厌只能工作的东西
-Tabc | -T, abc 处理起来真是无聊至极，String 层面不好处理因为有 -Tabc 这种连词的情况、Char 层面也不好处理因为有 -T abc…… 而且实在没必要上 Char解决，会引起处理与 shell 不协调。难道这个流就这么难以施用抽象性高的解析器？

唉，它写起来相当麻烦，Workflow 我现在还没想清楚还在渐进设计，但它相当重要，无法逃避。

准确的说 String 层面也可以处理，可我现在安排的 Parser 基本组合和输入流没有 mark/reset 的支持感觉不自在，而且一旦能够区分 -T 后面有没有配置的话，就得上 contextual 解析器了，实在是没必要。

Kotlin 官方都没有提供 Native 侧的 File API，KN 都这么久了还没官方接口
很多类还是得放 jvmMain 里写

这个项目 DOM TypeScript 侧还好，如果要手动处理 Markdown 部分的话感觉有点越俎代疱，最好还是找找 Markdown 的 DOM 库。