以上输入，反正就是只要有递归的情况，Box unwrap 全部会莫名其妙错误，我真是哔了狗了。
java.lang.ClassCastException: java.util.ArrayList cannot be cast to org.jison.Json

然后你调试看看，就会发现其实错误是在（目前因为没有特别处理 Parser 的格式化和完整面向对象建模，就是快速版本的而已，所以调试起来很麻烦）

kvPair.joinBy(tCOMMA)
.then { it.toMap() }.surroundBy(tLB, tRB) then { Json.Dict(it) }

//...

seq(partialList(1,4),
    ws, string, ws, tCOLON, element) then { Pair((it[0] as Json.Str).literal, it[1] as Json) }
seq(snd, ws, deferred { scalar }, ws).unwrap()

在这里，element 的解析结果以 selecting(1) 折叠居然是一些 spaces(ArrayList)！所以 1 难道不是永远代表 deferred { scalar }？莫名其妙，真是莫名其妙。
只不过是因为某个 selecting 的实例被递归使用了而已，所以就被破坏了，明显是作用域没想好，这种烂代码还有什么可以说的呢？

https://t.me/ice_learn_agda_internals

不愧是冰封哥，一天（大概是他在地球对面）时间就发了 47 条消息广播
这个频道居然是要重置 Agda？？？
……不愧是冰封

其实我应该用面向对象类，而不是 Function1<Feeder<T>, R> 这种方式来抽象 parser 的，现在一大堆 stack trace 不好看……

当然新的 ParserKt 有利用 Preety Print abstraction 的方式为每个 Parser 提供（无论调试抑或是实际报错都能用）的 Preety repr
我觉得 Parser 需要基于抽象类建模，而不是一个匿名的函数闭包……
这样的话，如果一些比较严谨化的东西也可以对 Parser 们用匿名 object 了（前提是大部分 parser 都要 open，至少是 seq 系），当然 deferred Parser 还是不可能省掉，要不然 initializer 无限递归或者拿到 null reference
其实也足够好了…… 死没办法

typealias Parser<R> = KParser<R?>
typealias PositiveParser<R> = KParser<R>
typealias PFailure = PositiveParser<Nothing>

inline val nParsed: Nothing? get() = null
inline val <PR: Any?> PR.isNotParsed: Boolean get() = this == nParsed
inline infix fun <PR: Any?, R1> PR.parsed(crossinline then: (PR) -> R1): R1 = this?.let(then) ?: this

唉…… Kotlin 不能 typealias PResult<R> = R? 这种（别怪我偏执）
要不然我可以写 ps(feeder) parsed { it.let(f) } otherwise { feeder.pfail(…) } 呢
不过用 (?.let) (?:) 也还算好


老用 extension function 对 JVM 来说也不是多好看，既然 compose parser 很常用不如就直接加入继承结构里

以上三次莫名其妙 bug 真是让我对编程有了新的认识，彻底教我做人了，原来光简单比🌶🐔还没用。

我哭了，虽然代码很难看而且缩进用 Visitor 没用到精髓，总算是完成了。

我要写别的东西…… 好无聊
ParserKt 的 mustSeq 是判断使用处可不可能 or 加的，好傻逼。
真是太愚蠢了，但是简直没有办法，难不成 or 还得手动给 subparsers 加逻辑？

简直蠢死了，为什么要看使用处；这么说用 Haskell 的多态方式还方便一些

or 就不能要 seq 是 PositiveParser，别处都要呢？不要就用 mustSeq 或者 toMust？可是那样代码真不知有多繁复，明明本来就应该是 must 的为什么还要默认 may？这就是多态，可是哪里来的多态、我为什么要多态

我用 toOptional() 怎么样？可是那样的话到处都是 toOptional，都怪 or，真是垃圾子解析器，虽然它可以说是最有用的一个了……

虽然对面向对象编程 or 根本不应该出现，为什么要有or，br 直接 peek&branch 不好么？

看来只能让 seq 比较独特，or 自动把所有不optional的subparser包一层optional好了

可是默认所有都 must，到处抛异常性能严重问题

也不对，mustSeq的思路本来就不对，错了为什么要抛异常？难道不可以在 or 的最后一个分支加 parserFail？不是一样么？or都用上了凭什么要toMust()？

错了统一不抛出异常、错误统一让 effect 子结构注册到流上下文里去（指使用 clamDown 镇静解析策略恢复默认值的情况）
其他错误直接让 parserFail 来提供报错信息
or 直接当成 br 用，后面跟个 parserFail 来保证质量，相当与在分支里写断言。

toMust 用来应对快捷需求的情况
依然是开心的一天。

Kotlin 可以用 sequence，ParserKt不是handle这种情况的，虽然可以写

新时代 HTTP request message parser。状态机化是为了解析遇到 buffer 不足时可以等待扩充并回到之前的位置重试

enum class State(val no: Int) {
  Begin(0), Method(1), RequestUri(2), Version(3),
  Header(4), Body(5), End(-1);
  inline val hasNext: Boolean get() = no != (-1)
  inline val next: State get() = State.values()[no.inc()]
}

internal fun parseRequest(data: ByteIterator) = sequence {
var state = State.Begin
while (state != State.End) {
var currentItem = when (state) {
State.Method -> ::parseMethod
State.RequestUri -> ::parseRequestUrl
State.Version -> ::parseVersion
State.Header -> ::parseHeader
State.Body -> ::parseBody
else -> impossible()
} (data)
//if (currentItem == null) throw InvalidHttpRequest()
if (currentItem != null) yield(currentItem)
else throw InvalidHttpRequest()
if (state != State.Header)
state = state.next
}
}

注意，上面的用的是 Kotlin 的 sequence 和 ByteIterator
不是可以自定义切片(Slice)的 SpanView(ReadOnlySpan)

如果需要等待也可以用 sequence 子解析器

新的修复版本：

enum class State(val no: Int) {
  Begin(0), Method(1), RequestUri(2), Version(3),
  Header(4), Body(5), End(-1);

  val hasNext: Boolean get() = no != (-1)
  val next: State get() = State.values()[no.inc()]
}

internal fun parseRequest(data: ByteIterator) = sequence {
var state = State.Begin
while (state != State.End) {
var currentItem = when (state) {
State.Method -> parseMethod(data)
State.RequestUri -> parseRequestUrl(data)
State.Version -> parseVersion(data)
State.Header -> parseHeader(data)
State.Body -> parseBody(data)
}
if (currentItem != null)
yield(currentItem)
else throw InvalidHttpRequest()
if (state.hasNext) state = state.next
}
}

我写解析流的状态机基本都是带 position 的，然后 consume 什么的每个子解析器都可以使用，consumed,slice 这些细节封装在父类里

把 consumed 抽提到 abstract class StateParser(protected var position: Cnt) 也可行
这种情况，consumed 就不需要靠 Parse 方法维护了，删去 consumed += currentConsumed、ParseMethod 里面的 return n 给换成 position += n 即可
Parse 方法解析完一个项目需要维护 data view 变量，可以向超类的逻辑要 view = data.slice(position)，就是面向对象的行为继承。

解析不了直接抛异常好了，面向对象设计也别太在乎异常费时间，有优化的

不过用 sequence 抽象没法在结束的时候返回解析成功失败，用 generateSequence 也是到返回 null 的时候停下

#Kotlin #Java

有个 CS 同班同学，电脑很差，关系蛮好的，要我作业，我把自己的代码人工混淆一波给他（坏笑.jpg

#Haha #PL #life #inm 🤣哈哈哈哈哈 还有Duck typing

#Android #China #coolapk 很久没见人间烟火的duangsuse喜闻乐见

挂个人，PeterCxy，俗称虾大。以前我第一印象觉得这人还行，然后今天手机刷机，有个问题由于自己知识浅薄不懂，他也正好是这个帖子的维护者，我就问了一下他（谨慎起见还特意注明自己不懂），没想到他直接给我 Block 了。我真不知道我哪里得罪恁了。各位以后小心和此人相处。