Ultimate Pea
Ultimate Pea
嗯嗯。 谢谢你的中肯的建议。 报错信心优化会在语言功能设计完善后进行。目前（初期几个版本）的工作重心还是在语言的功能（Features）的设计。 》 确定用户需要掌握的概念 应当进行一些语言风格方面的探索，但目前的所有反馈信息只是因为不这样反馈编译器/解释器就无法进行下一步的操作，目前（至少在0.2版本前）我的设计是最大程度告知用户出错的代码位置的大概信息。用户确实需要知道他们想要表达的是什么以及如何运用语言提供的结构（users have to know what they are doing）。 》反馈信息中的术语中文化 这个确实可以，虽然第一步可以暂时采取现代汉语的直译，但最终目标是采用一些具有传统文化内涵的翻译。 》即便与编程语言的语法不完全相同，至少风格上可以逐步接近 当然因为现代语言设计脱胎于西方逻辑学，在语法和翻译方面还有很多哲学方面的前沿工作要做。另外一点就是鄙人以为，程序语言是和自然语言的差别还是挺大的，只能做到外观上一致，骨子里还是不同的东西。
@nobodxbodon 其实在编程语言报错信息翻译方面，你有没有了解过的研究？ （尤其是目前直接的翻译晦涩难懂，不知道有没有从用户角度出发的报错信息研究）
根据最近的实践来看，报错信息确实是一个很复杂的问题。 我自己在编程的时候很多报错信息都要看半天是什么意思，程序写不对就会报错。 目前我能想到的方法是根据社区的反馈逐步改进报错信息。所以这一块我们要非常重视社区给予的反馈。
感谢讨论和建议，也祝您虎年快乐！
你的这个很厉害！Impressive Work! 看到这个项目能够激励新的项目也是挺开心的。 这个项目刚开始时也是基于入演算和一个基础的类型系统，现在正在往ML类型系统方向发展。个人薄见来看，lambda演算本身在构建大型程序方面会有三个不得不解决的问题，一是很难用lambda表达数据结构：lambda演算里一切皆函数，boolean是数据，在以后的pattern match会遇到很多困难。二是类型检查，大型程序离不开类型系统，如果设计像python/js那样在lambda演算中用动态类型，感觉也不太对。三是对于effect的处理，比如IO，在数据即函数的假设下，对于数据的观察可能会产生IO，这方面可能精心设计一下。 本项目最初（前100commit）也是使用lambda演算和一个非常基础的类型系统（Recursive Types+Product+Sum），但后来发现这些问题不得不解决时，还是开始转变使用类似ML的类型系统。 本项目最终应该也会加入大量的类似语法糖的东西来增加可读性，以及更便于编写，目前仍处于设计的初期阶段。我的想法是要设计一套用户可定义的语法糖，在当前的mixfix操作符基础上，加入更高级的比如自定义括号，列表等功能的支持，但还是有很长的路要走。
Lean 4的语法糖设计很值得本项目借鉴。 Link: https://github.com/arthurpaulino/lean4-metaprogramming-book
可以参考一下目前的豫言编译器生成的LLVM IR，也是使用了大量中文的。 [多态列.ll.txt](https://github.com/yuyan-lang/yuyan/files/13945071/ll.txt) 在我的设计中让LLVMIR成为豫言子集应当并非难事，但LLVM IR是作为编译中的中间表达形式，我并不能够看到中文化LLVM IR的价值，因为所有的LLVM IR能够表达的东西高级语言都可以非常方便地表达。 但如果目的是设计以中文为基底的底层语言，我认为一种可能的形式是 豫言编译器自己的某些中间表示形式，例如这种形式 [豫言IR_sample.txt](https://github.com/yuyan-lang/yuyan/files/13945091/IR_sample.txt) （*更正*：这种可能更直观些[豫言IR_sample2.txt](https://github.com/yuyan-lang/yuyan/files/13945453/IR_sample2.txt)），可能会更有价值：其他中文编程语言可以编译到豫言编译器理解的一种IR，然后豫言编译器可以生成后端代码。目前这种形式是以JSON字节码的方式呈现的，比如[多态列.擦除后形式.json](https://github.com/yuyan-lang/yuyan/files/13945098/default.json)，豫言编译器中的某些工作可以直接理解JSON字节码并进行变换。不过这些都处于非常早期的阶段。
是的，我之前说错了。豫言本身就可以被用做底层IR。
从另一个角度来说，豫言是一种高级语言，直接操作内存可行，但通常不推荐这样做。