c语言吧 关注：801,037贴子：4,370,648
不感兴趣
开通SVIP免广告
射命丸文 我觉得只有有类型和无类型之分，c/c++对类型要求很严格的，所谓的int能赋值给double，也只是编译器帮你做了强制转换，隐式转换和你自己转换的区别就是一个是编译器做一个是你做，不能这样就说说弱类型。c++如果你函数参数是string，传一个const char*进去，编译器就会帮你调构造函数构造一个string，但这并不能说明c++可以把const char*赋给string类型的变量，只是调用了定义好的函数转的。但是js却完全可以直接赋值甚至可以整形给字符串，虽然到最后底层实现也是要转的，只是这些转换的事都交给计算机做了。你先a="你好"，然后a=5，计算机只不过是把原来的那块内存扔掉，重新分配一个整形空间，然后存上5，取名为a而已，你还真以为在计算机里能够整形给字符串吗?
不感兴趣
开通SVIP免广告
> 只是很不习惯你把变量没有类型称为无类型
不是习惯不习惯的问题，不管从历史还是现实，这就是错的。
虽然少数人如 Robert Harper 之流是也有这种意见，认为所谓 dynamic typed = untyped = unityped ，但是这种意见从来不是主流观点。
这种观点的错误在于同时漠视研究传统和现实： PL 中所谓的类型本来就不限于对象语言的类型，所有 typing rule 中出现的 term 上特定位置的 annotation （具体由元语言的文法决定）都是 type （而不只是他家 ML 所谓的“静态”类型）；否则，所有非静态的类型检查检查的是什么玩意儿？
鼓吹静态类型才算类型的，大概都不知道“静态”这玩意儿究竟是怎么来的以及怎么在一个语言的对应理论中其作用的。至于像 Robert Harper 这种明知 phase 还要恶意混淆分析类型关联的作用(effect) 的对象语言和元语言来误导人，是要遭天谴的。
不是习惯不习惯的问题，不管从历史还是现实，这就是错的。
虽然少数人如 Robert Harper 之流是也有这种意见，认为所谓 dynamic typed = untyped = unityped ，但是这种意见从来不是主流观点。
这种观点的错误在于同时漠视研究传统和现实： PL 中所谓的类型本来就不限于对象语言的类型，所有 typing rule 中出现的 term 上特定位置的 annotation （具体由元语言的文法决定）都是 type （而不只是他家 ML 所谓的“静态”类型）；否则，所有非静态的类型检查检查的是什么玩意儿？
鼓吹静态类型才算类型的，大概都不知道“静态”这玩意儿究竟是怎么来的以及怎么在一个语言的对应理论中其作用的。至于像 Robert Harper 这种明知 phase 还要恶意混淆分析类型关联的作用(effect) 的对象语言和元语言来误导人，是要遭天谴的。
不感兴趣
开通SVIP免广告
关于什么算是 PL 中的类型，我另外举几个跟这吧主题比较相关的例子。
在 ISO C 中， lvalueness 在 spec 的意义上是一种和 type 无关的 semantic property （同时在特定的上下文中因为在 Constraint 出现，为实现其检查可以弱化为 syntactic property ），但这并不妨碍一个和 ISO C 等价的形式语义把 lvalueness 通盘当作 type 来处理，就算它不是 ISO C 定义的 type 。类似地， ISO C++ 的 value category 以及 Rust 的 placement/value 的划分也具有相同的特征。
理由是，这些特性完美地符合静态类型需要的“类型”的普遍要求： statc & following terms 。
而且，一定程度上讲，就算强行只管静态类型，C 的 lvalueness 和 C++ 的 value category 是比这些语言的 spec 中明确定义的所谓 type 更有资格作为类型的 PL 意义上的类型。
实际上， C 和 C++ 的所谓 type 比上述的类型更复杂。例如 ISO C99 开始为了补全之前语义漏洞明确的 effective type ，以及 C++ 所谓的 dynamic type ，这些都不是“静态”的类型（反正 Robert Harper 看来无视这些了）。而反过来，lvalueness 和 value category 是要求在 translation phase 7 之前确定而彻底静态的。
当然，这不表示不能把这些东西搞成 latent 的。我的语言实现里就包含了这些东西（虽然我不想引入这些破烂但是要排除 GC 又不想搞更屑的 refinement type 之类，原则上无法避免），最近加上了类似 rvalue reference 而让类似 std::forward 的屑更麻烦了……因为类似 C++ 的 decltype() 和 decltype(()) ，实际上 object type 和 expression type 是两回事——而后者才是传统静态类型鼓吹者所谓的静态类型的来源。
在 ISO C 中， lvalueness 在 spec 的意义上是一种和 type 无关的 semantic property （同时在特定的上下文中因为在 Constraint 出现，为实现其检查可以弱化为 syntactic property ），但这并不妨碍一个和 ISO C 等价的形式语义把 lvalueness 通盘当作 type 来处理，就算它不是 ISO C 定义的 type 。类似地， ISO C++ 的 value category 以及 Rust 的 placement/value 的划分也具有相同的特征。
理由是，这些特性完美地符合静态类型需要的“类型”的普遍要求： statc & following terms 。
而且，一定程度上讲，就算强行只管静态类型，C 的 lvalueness 和 C++ 的 value category 是比这些语言的 spec 中明确定义的所谓 type 更有资格作为类型的 PL 意义上的类型。
实际上， C 和 C++ 的所谓 type 比上述的类型更复杂。例如 ISO C99 开始为了补全之前语义漏洞明确的 effective type ，以及 C++ 所谓的 dynamic type ，这些都不是“静态”的类型（反正 Robert Harper 看来无视这些了）。而反过来，lvalueness 和 value category 是要求在 translation phase 7 之前确定而彻底静态的。
当然，这不表示不能把这些东西搞成 latent 的。我的语言实现里就包含了这些东西（虽然我不想引入这些破烂但是要排除 GC 又不想搞更屑的 refinement type 之类，原则上无法避免），最近加上了类似 rvalue reference 而让类似 std::forward 的屑更麻烦了……因为类似 C++ 的 decltype() 和 decltype(()) ，实际上 object type 和 expression type 是两回事——而后者才是传统静态类型鼓吹者所谓的静态类型的来源。
