duangsuse::Echo
sudo npm install --save-dev @types/node npm update --save-dev @types/node 好了重写马上就完成了!
唉,还是有很多很多的问题,只能等着了……
还有 绝句第一稿的一些问题要改…… (虽然马上也不看第一稿了)
还有 Kotlin 关系式博文要写
还有 Literate Kotlin 工具要写……
ParserKt 也可以改一下了……
……
还有 绝句第一稿的一些问题要改…… (虽然马上也不看第一稿了)
还有 Kotlin 关系式博文要写
还有 Literate Kotlin 工具要写……
ParserKt 也可以改一下了……
……
duangsuse::Echo
艹,还不如用 FP.js 的解析器呢(笑话
我终于彻底搞明白 lastItem, peek, next, consume 这些的区别了……
噢……原来 SaveIterator 和 PeekConsume 有本质上的区别啊…… 原来允许不移动数据指针和保存上一项是不一样的啊…… 原来真的不可能直接兼容 takeWhile 啊……
噢……原来 PeekConsume 实际上不能算 Iterator 啊……
噢……原来 tailConsume 是为了方便写解析器而对整体数据输出无影响,原来 tailConsume 也不一定得做成 boolean 判断的形式,只是最后一项得能 yield 出就可以了,Java 形式必须兼容 hasNext 才有 boolean tailConsumed = false;
噢……原来 ES6 Generator 版的 PeekConsume 实现 tailConsume 会更简单啊……
原来流处理应该那样分析啊…… 其实序列 1,2 算算 takeWhile (>=2) 什么的已经足够,再多看看索引 index 抵胡想半小时。
噢……原来 SaveIterator 和 PeekConsume 有本质上的区别啊…… 原来允许不移动数据指针和保存上一项是不一样的啊…… 原来真的不可能直接兼容 takeWhile 啊……
噢……原来 PeekConsume 实际上不能算 Iterator 啊……
噢……原来 tailConsume 是为了方便写解析器而对整体数据输出无影响,原来 tailConsume 也不一定得做成 boolean 判断的形式,只是最后一项得能 yield 出就可以了,Java 形式必须兼容 hasNext 才有 boolean tailConsumed = false;
噢……原来 ES6 Generator 版的 PeekConsume 实现 tailConsume 会更简单啊……
原来流处理应该那样分析啊…… 其实序列 1,2 算算 takeWhile (>=2) 什么的已经足够,再多看看索引 index 抵胡想半小时。
duangsuse::Echo
ES6 的 iterator 真是麻烦死了,hasNext/next 根本分不清
还是 Ruby/Python 式的
StopIteration 好……class PeekConsume<T> {
iter: Iterator<T>
last: IteratorResult<T>
constructor(iter: Iterator<T>) {
this.iter = iter;
this.last = iter.next()
}
*iterator() {
if (this.last.done) return;
yield this.last;
this.last = this.iter.next()
}
get peek() {
return this.last.value;
}
} 这个很正常,但是 peek 和 next 不在一个地方访问,所以不能直接用 Generator 写。
比如有流 1,2,3
对上面使用真假判断的版本
new Peek([1,2,3].values())不需要判断是否 hasNext(),也可不用 Generator,因为它实际上就是
peek=1, next=undone(1); this.last = undone(2)
peek=2, next=undone(2); this.last = undone(3)
peek=3, next=undone(3); this.last = done()
peek=undefined, next=done(); this.last = done()
fun next() = lastItem.also {...}
Kotlin 里面,我们利用 hasNext 和 tailConsumed 判断是否更新 lastItem、内部流结束后是否要结束外包流,以及那时 lastItem 是什么,这里我们不需要,因为 tailConsumed=true 和 last={value: undefined, done: true} 是等价的,不需要预先判断,而且 Generator 里你不需要抛出任何异常。对上面使用真假判断的版本
new Peek([1,2,3].values())
peek consume case
1 1 !askNext.done
2 2 !askNext.done
3 3 askNext.done, !tailConsumed
3 3 askNext.done, tailConsumed
undefined undefinedTypeScript 没 extension 和 Kotlin 的 functional extension, like
其中,last 是 inline block
写别的语言就跟吃 💩 一样,Java 那种东西是根本救不了了。学 Java 救不了中国人。
不知道那些语言的设计者脑子里都有啥玩意,为啥 TypeScript 顶着强制要求所有
TypeScript 的 constructor 比起辣鸡 Java 简直可以说是没啥改进,除了换成了关键字定义省脑子标准化,该有的
该省的你们留着、不该省的你们简写、不该有的你们加上,我去我还是写『脚本语言』算了,至少第一眼看起来是好一些。
also: T.(Consumer<T>) -> T, let: T.((T) -> R) -> R 实在是太难了!我感觉我的 oldLast = last; last = nextLast(); return oldLast; 和辣鸡 Java 的没区别啊?为什么我不能写 return last.also { last = nextLast() } ?其中,last 是 inline block
T.also(...): T 的一个参数,而这个参数在块里没有被使用,最后此块会返回原 receiver T 的值,同时原 last 也会被重新赋值,oldLast 就是 also 的隐式参数 it,理论和实际一样优雅高效。写别的语言就跟吃 💩 一样,Java 那种东西是根本救不了了。学 Java 救不了中国人。
不知道那些语言的设计者脑子里都有啥玩意,为啥 TypeScript 顶着强制要求所有
(name:T) => R 类型标记都得加一个 name 的弊端,还是要那样设计,而且 constructor 看起来又那么头晕那么冗余,我真是不明白。TypeScript 的 constructor 比起辣鸡 Java 简直可以说是没啥改进,除了换成了关键字定义省脑子标准化,该有的
this.filed = field; 一个也不能省。该省的你们留着、不该省的你们简写、不该有的你们加上,我去我还是写『脚本语言』算了,至少第一眼看起来是好一些。
fun List<String>.preetyShow(seprator: String = ", ", lastSeprator: String = " and "): String = if (size == 0) ""
else this.slice(0 until lastIndex).joinToString(seprator) + lastSeprator + this.last()
甚至还可以fun List<String>.preetyShow(seprator: String = ", ", lastSeprator: String = " and "): String
= this.lastOrNull()?.let { slice(0 until lastIndex).joinToString(seprator) + lastSeprator + it } 如果觉得
if (size==0) 或者 if(isEmpty()) 不好看,还可以fun <R> Collection<*>.takeIfEmpty(value: R): R? = value.takeIf { isEmpty() } fun List<String>.preetyShow(seprator: String, lastSeprator: String) = takeIfEmpty("") ?: slice(0 until lastIndex).joinToString(seprator) + lastSeprator + last() 顺便提一句,
Collection<T> 里其实已经有 takeIfEmpty 的 functional 版本了,我也可以写 takeIfEmpty {value} 的。所以说 Kotlin 的 elvis operator (?:)、safe access (?.) 是对 Java 所谓的『Nullability问题』化腐朽为神奇,变成了不得、对提升语言表现力有极大作用的宝物,不少函数式编程语言都没法表现得那么直白。
所以说 Java 真是烂泥扶不上墙啊,果然修问题要修在 root cause 上,就是语言设计辣鸡,『生态』『工具』再好也只会制造更多问题。 #PLT #statement #Java #Kotlin
Kotlin 整门语言都是极其对称的,fun、val、class、object,都是写在前面,放在一个地方的东西如 fun, val, var 基本连关键字长度都是一致的,有哪门语言想见过这点???都是只考虑『可以表达』、从不想『如何好看地表达』
只想着『完成就好』,从不想如何『更好地完成』,你们这样子是不行的! 🐸
就像只计划着『图灵完全』的语言,是没办法做成工程可以实用的形式的,而且有些更学术的语言甚至都不图灵完全,因为它们还能不是为了解决『如何定时喂猪』那种问题设计的,所以只有追求更高的东西,而后自然而然能够以更好的方法完成更低的东西,只解决问题、从不制造多余的问题。
duangsuse::Echo
这叫『抽提』,是让代码变好看一点的第一步,当然你可以认为这时它只是更难理解了一点;其实这的确只是第一步——没有第一步,何来累积优化? #JavaScript #ES6 #web
更大的改进都是从这时看起来『善恶不明』的抽提开始的,没有一次次小的重构做铺垫,就发现不了代码可能存在更多可以提升的因素,像极了现代编译优化器的 pass-by-pass 架构。
不过 Generator 真的好方便啊!
TSC 默认的实现也和我之前那个 Essay-Java-CtrlSt-Based-Generators 差不多,打断表达式来求值
TSC 默认的实现也和我之前那个 Essay-Java-CtrlSt-Based-Generators 差不多,打断表达式来求值
GitHub
duangsuse-valid-projects/Essay-Java8-CST-Based-Generators
Control structure / java.util.Iterator / class instance private state based suspend functions just like C# yield state machine - duangsuse-valid-projects/Essay-Java8-CST-Based-Generators
折腾了半天,总算是解决了加载时序的问题…… addEventListener 真是不称职,为什么 defer 脚本很多时候就不能执行
#dev 真的开始怀念以前编程的时候,不需要想太多;上次的 Kotlin JS/JVM 的 Binarie 现在没写完,要写完的话其实要给不同平台兼容接口…… 很麻烦呢
待在一门语言、一个环境还真心不累,写点二进制序列化辅助库什么的都太简单了,我太难了!
待在一门语言、一个环境还真心不累,写点二进制序列化辅助库什么的都太简单了,我太难了!