我要写别的东西…… 好无聊
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 了。我真不知道我哪里得罪恁了。各位以后小心和此人相处。

讲个笑话，他就是看不起你，所以怎么看你都傻逼。
要是一开口/dev/,kmodule,coreutil，说不定还不至于block，当然也说不定。

我也经常看不起一些人的，不过我觉得这是不应该的，所以我不会表现出来，也会努力克制，今后也会努力克制的。
其实啥东西，老是分什么高端低端，就纯属搞错重点了。大家玩技术，开心就好，也不要总管弄出个什么玩意来。
能给建议的给点建议，不要把自己放得太高，不要对别人提太高要求，好好学习、好好创作、努力试着去向『传播者』的方向走就行了。

哎呀，其实我早就想给我的 pr.py 加上 -srand 选项的，可惜最后没去弄

#tech #CS