Forwarded from Deleted Account
肯定是尽可能用 foreach
如果是
注：命名 Iterator 请依照项目代码风格，非最佳实践。
如果是
while (input.hasNextLine()) iter.next() 它肯定没意见注：命名 Iterator 请依照项目代码风格，非最佳实践。
Forwarded from Deleted Account
public relation 就是伪科学
用欺骗强奸人们的感情，真心都没有还提什么“关系”
用欺骗强奸人们的感情，真心都没有还提什么“关系”
#dev 下去散步时关于 声名、简单、高深 莫名文艺抒情了一下
关于 ParserKt 在实现绝句介词/后缀（也即“记法”） 和名字的混合解析，大概考虑好了。就是给名字专门实现解析器，然后把记法解析器写成 Either<String> 的形式，Right 的时候停止 concat name parts，记法解析器只返回 Stated 流里之前存下的结果。这种方法可以实现 one-pass。
我就是觉得程序猿要学会并适应“带着枷锁编程”，不能太松散豪放了。
考虑了一下 ParserKt v3 不参 v2 源码的重写，我觉得已经比较成熟了，不会有大问题。
后天 v2 cleanup，然后准备 v3 和 faster-parserkt
我不可能和 kotlin 的 IntArray, FloatArray 弄 CharFeed 的，那样的“优化”简直不可接受……
关于 ParserKt 在实现绝句介词/后缀（也即“记法”） 和名字的混合解析，大概考虑好了。就是给名字专门实现解析器，然后把记法解析器写成 Either<String> 的形式，Right 的时候停止 concat name parts，记法解析器只返回 Stated 流里之前存下的结果。这种方法可以实现 one-pass。
我就是觉得程序猿要学会并适应“带着枷锁编程”，不能太松散豪放了。
考虑了一下 ParserKt v3 不参 v2 源码的重写，我觉得已经比较成熟了，不会有大问题。
后天 v2 cleanup，然后准备 v3 和 faster-parserkt
我不可能和 kotlin 的 IntArray, FloatArray 弄 CharFeed 的，那样的“优化”简直不可接受……
Forwarded from 🧶 ᑎᗩᔕЧ
haskell 可以玩一些
的东西
class F a where
f :: a -> Int
instance F Int where
f = id
instance F String where
f = read
的东西