duangsuse::Echo
呃... 既然都说到这一步了就顺带讲一下我之前关于 动态作用域/词法作用域的见闻,虽然我知道没人感兴趣的。 动态作用域(dynamic scoping)就是你们能想到的,末端是全局作用域的嵌套表。 理解为栈,当前层的key被赋值、最顶层的表里的key被取值,所以栈帧销毁后解析会有不同的结果。 动态作用域没什么问题,也被用于诸如(嵌套命名空间)类型名解析的地方,除非函数可以作为值——比如 (set! a 1) (def get-kst() (lambda () a) ) (def main(a) (get…
梗概一下 Mivik/kamet 自我停止更新后增加特性的建模要点 #Kotlin #CS #CE #PLT
== 参数化类型 类型形参
== Traits
目前还不支持 (intersection) upper-bounds
既有 Nothing,Unit, bool/char, (U) byte/short/int/long/float/double, Array/Struct/Function
Pointer,Reference(虽然我觉得都是 TypeModifier, 而且它们的 isConst 是共用的)
Named,TypeParameter(的包装)
== Dynamic Type (trait objects)
== 参数化类型 类型形参
val name: String== 类型推导 已知表:
check, toSting
Simple(name)
data Trait(name, trait) check = type.implemented(trait) || (type is Type.Dynamic && type.trait == trait)
data This(trait) : Trait("This", trait)
TypeParameterTable (ThreadLocal)<R> scope(block: TypeParameterTable.() -> R): R
set(typeParams: List<TypeParameter>, typeArgs: List<Type>)
map(typeParams): List<Type>
mapOrNull(typeParams) List<Type>?
equals(typeParam: TypeParameter, type: Type): Boolean = isEnabled && ...
这些命名我觉得应该叫 putActual( "<T, R>", "<Int, String>" ), fill("<T, R>"), fillOrNull, makeEqual(typeParam, type) == Traits
sealed /*data*/ class Trait(val name: String)然后有子类(抽象和未解析都属 Abstract)
implementedFunctions: Iterable<Function.Generic>
abstractFunctions: List<Function.Dynamic>
prototypes: List<Prototype>
abstract class Abstract(name: String) : Trait(name)class Base internal constructor 大概就是默认实现,加个
Named(name: String) : Abstract(name)
rename(newName)
Generic(base: Trait, typeParams: List<TypeParameter>): Abstract(genericName(base.name, typeParams))加个
resolveGeneric(typeArguments: List<Type>): Trait.Actual(generic: Trait, typeArgs: List<Type>) : Abstract(actualGenericName(generic.name, typeArgs))其 Impl:
data class TraitImpl(trait: Trait, type: Type, functions: List<Function.Generic>) { val table: LValue }
会生成一个虚表 (constArray: Function.Static) ,这依赖 constant method ordering. 然后可以选择是 vtable 存 struct 里还是用 fat pointer (inst,vtable)目前还不支持 (intersection) upper-bounds
<T: Closeable>
== 类型拓展既有 Nothing,Unit, bool/char, (U) byte/short/int/long/float/double, Array/Struct/Function
Pointer,Reference(虽然我觉得都是 TypeModifier, 而且它们的 isConst 是共用的)
Named,TypeParameter(的包装)
Generic(val base: Type, val typeParameters: List<com.mivik.kamet.TypeParameter>): Abstract()嗯…… Abstract 子类而不直接在
Actual(val generic: Type, val typeArguments: List<Type>): Abstract()
This(val trait: Trait) : TypeParameter(com.mivik.kamet.TypeParameter.This(trait))
UnresolvedThis : Abstract()
sealed class 里面抛错误是个不错的设计,但或许应该叫 Abstracted 或 Abstraction?== Dynamic Type (trait objects)
Dynamic(val trait: Trait, val type: Type?) : Abstract()
DynamicReference(val trait: Trait, val type: Type?, isConst: Boolean): Reference(Dynamic(trait, type), isConst)
Impl(val trait: Trait) : Abstract()
GitHub
GitHub - Mivik/kamet: kamet - a simple programming language written in Kotlin.
kamet - a simple programming language written in Kotlin. - Mivik/kamet
duangsuse::Echo
梗概一下 Mivik/kamet 自我停止更新后增加特性的建模要点 #Kotlin #CS #CE #PLT == 参数化类型 类型形参 val name: String check, toSting Simple(name) data Trait(name, trait) check = type.implemented(trait) || (type is Type.Dynamic && type.trait == trait) data This(trait) : Trait("This", trait)…
Mivik 真的很厉害呢…… 不愧是 OI 生,知道那么多我不懂的东西 (汗)
之前写的 Android 文本编辑代码高亮视图也是太大佬了,我不敢想……
类型推导里的 makeEqual 也挺有趣的,这不就是 unification 里 unify 算法的基本做法吗:
这里用 null 与否来判断是否成功,但总体和
ps. Kotlin 的 scope function 真的绝赞
Mivik 其实并不是一个 Rust 狂魔,但他有能力把 Rust 与 Kotlin 结合在一起成为他自己的 Kamet ,这不是死知识或者单纯的抄袭,在前人的基础上他也做到了融合与扩展。
或许在 LLVM 的帮助下设计一个编译器并不困难,仅仅复刻一门语言写个蓝皮书也不困难,但从零开始设计并实现一门类似 C++ 的语言绝对不是个小工程;即便有 Kotlin 的帮助,也足以显现扎实的理论基础和工程水平。 把注意力全部放在功能拓展上,是和仅仅耍弄术语概念、刻意编写晦涩臃肿的代码、努力营造“专业软件”氛围的工程师完全不同的方向。 一点名词也不用却做到了它们代表的真实内涵,这才是「专业」所不能够理解的深刻。
即便作为普通的 OI 生,我相信他也是非常有能力的一个,以后在大学也绝对是能进入顶级计算机科学社的水平
之前写的 Android 文本编辑代码高亮视图也是太大佬了,我不敢想……
类型推导里的 makeEqual 也挺有趣的,这不就是 unification 里 unify 算法的基本做法吗:
sealed class Sym {
data class Var(val name: String): Sym()
data class Val(val value: Any?): Sym()
}
fun State.unify(a:Sym, b:Sym): Any? {
val va=get(a); val vb=get(b)
return when {
(a == b) -> a
(a is Sym.Var) b.also { assign(a, b) }
(b is Sym.Var) a.also { assign(b, a) }
else -> null
}
} 这里用 null 与否来判断是否成功,但总体和
makeEqual(typeParam, type) 是一样的ps. Kotlin 的 scope function 真的绝赞
Mivik 其实并不是一个 Rust 狂魔,但他有能力把 Rust 与 Kotlin 结合在一起成为他自己的 Kamet ,这不是死知识或者单纯的抄袭,在前人的基础上他也做到了融合与扩展。
或许在 LLVM 的帮助下设计一个编译器并不困难,仅仅复刻一门语言写个蓝皮书也不困难,但从零开始设计并实现一门类似 C++ 的语言绝对不是个小工程;即便有 Kotlin 的帮助,也足以显现扎实的理论基础和工程水平。 把注意力全部放在功能拓展上,是和仅仅耍弄术语概念、刻意编写晦涩臃肿的代码、努力营造“专业软件”氛围的工程师完全不同的方向。 一点名词也不用却做到了它们代表的真实内涵,这才是「专业」所不能够理解的深刻。
即便作为普通的 OI 生,我相信他也是非常有能力的一个,以后在大学也绝对是能进入顶级计算机科学社的水平
duangsuse::Echo
编程时,命名使用不常见的英文单词应该被替换吗?例: onEncountered -> onHappend
duangsuse 除了泛向的 CLI/复用库设计 外可能没有什么专业,除了 codegen / bin+text serialize 俩好像也没啥了,不能后端也不能前端 GUI 也不太会... 太泛泛了
Kamet 里又出现了一次 Prototype 这个词, Lua 里这个词不止是
编程语言和自然语言是有区别的,我们是真的对严谨性有要求,而且不广为认知地,比数学更严谨。
所以我个人观点绝对是讨厌利用不常见的英文单词的,比如 lift, comprehension 等(往往这些词还有一大堆变形会被人混用)。
绝对不要以为你是在用英文编程就可以自由用英文的 trick 了,编程的世界只有结构关系逻辑,没有自然语言的理解,所以命名应该直白地反应其构件与其他构件间的关系,直白的东西自然是无歧义的。指望代码读者了解你心理的小九九很不明智。
说起来
Kamet 里又出现了一次 Prototype 这个词, Lua 里这个词不止是
FunctionDecl 还是包含其实现 code 的,真不知道该不该有 prototype, 它的语义太混乱了编程语言和自然语言是有区别的,我们是真的对严谨性有要求,而且不广为认知地,比数学更严谨。
所以我个人观点绝对是讨厌利用不常见的英文单词的,比如 lift, comprehension 等(往往这些词还有一大堆变形会被人混用)。
绝对不要以为你是在用英文编程就可以自由用英文的 trick 了,编程的世界只有结构关系逻辑,没有自然语言的理解,所以命名应该直白地反应其构件与其他构件间的关系,直白的东西自然是无歧义的。指望代码读者了解你心理的小九九很不明智。
说起来
Map<K, V> 和 Map<K 的区别也挺奇怪的…… 词法处理的时候会遇到歧义问题,不知道不用词法处理会如何...Forwarded from dnaugsuz
顺便: 发了点关于设计模式的文章
https://t.iss.one/dsuse/14704
查了一下 interface Resolvable 只在
开始还以为是要节省内存分配,把
https://t.iss.one/dsuse/14704
查了一下 interface Resolvable 只在
sealed class Function : Resolvable 里用了啊…… 而且 val resolved:Boolean 也没覆盖开始还以为是要节省内存分配,把
Type.Named 给改成 var type:LType 的了呢,所以有 resolved ,这种做法也不用 lazy 🤔Telegram
duangsuse::Echo
用 Visitor 你可以实现计算器(add a b = a + b) 和编译器(see (it:Name) = print(it.str) )
interface Eval<out T> { fun eval(): T }
sealed class Calc: Eval<Int> {
/* literal number */
data class L(val n: Int): Calc() { override fun eval() = n }
data class Op(val a: Calc…
interface Eval<out T> { fun eval(): T }
sealed class Calc: Eval<Int> {
/* literal number */
data class L(val n: Int): Calc() { override fun eval() = n }
data class Op(val a: Calc…
https://github.com/OrkoHunter/python-easter-eggs #Python #dontknow
https://www.python.org/dev/peps/pep-0020/#id2
https://www.python.org/dev/peps/pep-0020/#id2
import this
https://www.python.org/dev/peps/pep-0401/ 只能用 <> 而不是 !=GitHub
GitHub - OrkoHunter/python-easter-eggs: Curated list of all the easter eggs and hidden jokes in Python
Curated list of all the easter eggs and hidden jokes in Python - OrkoHunter/python-easter-eggs
Forwarded from Rachel 碎碎念 (IFTTT)
麻脑壳,Java / Kotlin 工程,尤其是要牵涉到 Gradle / Maven 的那种也太重了,要是能和 Python 一样脚本语言般轻量多好
学协程想写点什么测试,在 Android 工程里面搞实验是真的麻烦,让 VS Code 来启动一个新的具有 Gradle 支持的 Kotlin 工程…得了吧,我还不如乖乖开个新 Android 工程(— Rachel 呱 (@Rachel030219) August 24, 2020
学协程想写点什么测试,在 Android 工程里面搞实验是真的麻烦,让 VS Code 来启动一个新的具有 Gradle 支持的 Kotlin 工程…得了吧,我还不如乖乖开个新 Android 工程(— Rachel 呱 (@Rachel030219) August 24, 2020
Twitter
Rachel 呱
麻脑壳,Java / Kotlin 工程,尤其是要牵涉到 Gradle / Maven 的那种也太重了,要是能和 Python 一样脚本语言般轻量多好 学协程想写点什么测试,在 Android 工程里面搞实验是真的麻烦,让 VS Code 来启动一个新的具有 Gradle 支持的 Kotlin 工程…得了吧,我还不如乖乖开个新 Android 工程(
Forwarded from Rachel 碎碎念 (IFTTT)
翻了翻以前自己的源码,感觉自己至少还是在进步
从原来「it works!」不求甚解,到现在每写一句都要思考「为什么这一句写在这里?」「这样修复 bug 原理是什么?」「我能不能更好地解耦?」
bug 还是多,引入的额外思考更让本不灵光的脑子偶尔迷迷糊糊,但至少我自己开始去问 why 了— Rachel 呱 (@Rachel030219) September 6, 2020
从原来「it works!」不求甚解,到现在每写一句都要思考「为什么这一句写在这里?」「这样修复 bug 原理是什么?」「我能不能更好地解耦?」
bug 还是多,引入的额外思考更让本不灵光的脑子偶尔迷迷糊糊,但至少我自己开始去问 why 了— Rachel 呱 (@Rachel030219) September 6, 2020
Twitter
Rachel 呱
翻了翻以前自己的源码,感觉自己至少还是在进步 从原来「it works!」不求甚解,到现在每写一句都要思考「为什么这一句写在这里?」「这样修复 bug 原理是什么?」「我能不能更好地解耦?」 bug 还是多,引入的额外思考更让本不灵光的脑子偶尔迷迷糊糊,但至少我自己开始去问 why 了
Forwarded from 层叠 - The Cascading
江苏省苏州市推出「文明码」,全国首创。
刚想说这《黑镜》在现实中的完美演绎竟是如此真实,却发现这其实不是大家第一次这么说了 [1]。
> I promise you we didn't sell the idea to the Chinese government!
src: https://mp.weixin.qq.com/s/xMYK1pmsqT94fWcEPbt5ww
alt-src: https://telegra.ph/%E5%81%A5%E5%BA%B7%E7%A0%81%E8%BF%98%E6%B2%A1%E8%B5%B0%E6%96%87%E6%98%8E%E7%A0%81%E5%8F%88%E6%9D%A5%E4%BA%86-09-04-3
1. 参见《黑镜》第三季第一集《急转直下》 ("Nosedive")。
刚想说这《黑镜》在现实中的完美演绎竟是如此真实,却发现这其实不是大家第一次这么说了 [1]。
> I promise you we didn't sell the idea to the Chinese government!
src: https://mp.weixin.qq.com/s/xMYK1pmsqT94fWcEPbt5ww
alt-src: https://telegra.ph/%E5%81%A5%E5%BA%B7%E7%A0%81%E8%BF%98%E6%B2%A1%E8%B5%B0%E6%96%87%E6%98%8E%E7%A0%81%E5%8F%88%E6%9D%A5%E4%BA%86-09-04-3
1. 参见《黑镜》第三季第一集《急转直下》 ("Nosedive")。
Weixin Official Accounts Platform
“健康码”还没走,“文明码”又来了
魔幻
Rachel 碎碎念
麻脑壳,Java / Kotlin 工程,尤其是要牵涉到 Gradle / Maven 的那种也太重了,要是能和 Python 一样脚本语言般轻量多好 学协程想写点什么测试,在 Android 工程里面搞实验是真的麻烦,让 VS Code 来启动一个新的具有 Gradle 支持的 Kotlin 工程…得了吧,我还不如乖乖开个新 Android 工程(— Rachel 呱 (@Rachel030219) August 24, 2020
记得协程的 Intrinsic 是有 create, resume, suspendOrReturn
什么时候实现 LiteralKt 就不需要为项目创建操心了……
什么时候实现 LiteralKt 就不需要为项目创建操心了……
Forwarded from moke 的 日常分享、吐槽和动态
Forwarded from ㅤ 🅂🄲🄷🅆🄰🅁🅉 🅶🅴🅻🅱🅴🅽
知乎专栏
『寒舟』的自白
大家好,我是许海浩,寒舟的作者。这几天的风评叨扰大家了。前不久上线了一款产品,不知怎的就火了。我只是个普通开发者,这几天整个人一直是懵逼的。但事情愈演愈烈,还是希望借此平台给大家阐述一下我在干什么。…
真是不知道怎么优化 Rust 式的卫生宏与 Scala 式的 Def Macro, 连 Java 的 annotation processor codegen 也觉得不够。
Forwarded from Product Hunt Hot
Parsify Desktop (Productivity, Open Source, Education, Text Editors)
Extendable calculator for the 21st century ⚡
产品官网🔗
在 Product Hunt 上的页面🔗
Extendable calculator for the 21st century ⚡
产品官网🔗
在 Product Hunt 上的页面🔗
Forwarded from duangsuse Throws