我们人类自然语言说话的每个词，串起来每句话的理解，视乎也是一个栈式虚拟机样。
2 个赞
甚至说参数可以出现在任意地方，参数名称的特定组合会不会就是方法函数，名可名非常名，不管参数名，方法名，类型名称，所有的说到底都是名称而已。比如定义啦N个方法，取的名字是第1个方法，第2个方法…以此类推，第N个方法，这N个方法的排列组合就又可以产生无数方法，这其中的第（N）个方法中的N就是这一类方法的参数啊，说白啦只需要知道是哪个方法，也没有说非要知道这个方法叫什么名字啊。
我感觉这个东西感觉比较难做…
1 个赞
fn 第N个方法(self:Int) -> (()->Unit) {
print("\n"+"第\(self)个方法已经执行。")
match self{
1=>方法A
2=>方法B
3=>方法C
_=>方法D
}
}
fn 第(self:Int)->Int{
self
}
fn 个方法(self:Int) -> (()->Unit) {
print("\n"+"第\(self)个方法已经执行。")
match self{
1=>方法A
2=>方法B
3=>方法C
_=>方法D
}
}
fn 被执行(self:Unit)->Unit{}
fn init{
第N个方法(1)
print("\n")
第N个方法(2)()
print("\n")
第N个方法(3)()
print("\n")
第N个方法(4)()
print("\n")
2.第N个方法()()
print("\n++++++++++++++++++++++")
第(1).个方法()().被执行()
print("\n")
第(2).个方法()().被执行()
print("\n")
第(3).个方法()().被执行()
print("\n")
第(4).个方法()().被执行()
print("\n")
}
fn 方法A() -> Unit {
print("方法A已经执行！")
}
fn 方法B() -> Unit {
print("方法B已经执行！")
}
fn 方法C() -> Unit {
print("方法C已经执行！")
}
fn 方法D() -> Unit {
print("方法D已经执行！")
}
总感觉变量名用中文来命名有点变扭，中英文混合观感不好。一个汉字看多了，就容易出现视觉疲劳，不认识这个字了。
2 个赞
<火山程序 类型 = "通常" 版本 = 1 />
方法 按钮_被单击 <接收事件 类型 = 整数>
参数 来源对象 <类型 = 按钮>
参数 标记值 <类型 = 整数>
{
如果 (标记值 <= 0)
{
如果 (来源对象 == 按钮2)
{
新增布局数组.删除所有成员 ()
新增按钮数组.删除所有成员 ()
}
否则
{
变量 布局所加入位置 <类型 = 整数>
变量 新布局 <类型 = 我的布局1>
布局所加入位置 = 新增布局数组.加入新成员 (我的布局1)
((我的布局1)新增布局数组.取成员 (布局所加入位置)).创建容器组件 (本对象, 80, 20 + 新增布局数组.取成员数 () * 60) // 注意必须基于数组的返回对象创建容器组件,否则其内部子组件的自动事件挂接将失效.
新布局 = (我的布局1)新增布局数组.取成员 (布局所加入位置) // 不涉及到事件挂接的操作可以使用另一个被赋值的对象变量
新布局.编辑框1.获取焦点 ()
变量 按钮所加入位置 <类型 = 整数类>
变量 所加入按钮 <类型 = 按钮>
挂接事件 ((按钮)新增按钮数组.加入并返回新成员2 (按钮, 0, 按钮所加入位置), 按钮所加入位置.值 + 1) // 注意此处必须在数组的返回对象上挂接
所加入按钮 = (按钮)新增按钮数组.取成员 (按钮所加入位置.值)
所加入按钮.创建组件 (本对象, 20, 20 + 新增布局数组.取成员数 () * 60, 50, 50) // 由于按钮不为容器组件,因此不涉及到其内部子组件的自动事件挂接,所以可以基于另一个被赋值的对象变量进行创建.
常量 所使用图标资源 <类型 = 图标资源 值 = "button.ico">
所加入按钮.图标 = 所使用图标资源
}
}
否则
{
变量 布局变量1 <类型 = 我的布局1>
布局变量1 = (我的布局1)新增布局数组.取成员 (标记值 - 1)
信息框 ("布局中的编辑框内容: " + 布局变量1.编辑框1.内容)
}
返回 (0)
}
当你看到全屏都是中文的程序该怎么办哦！
moonbit里面函数是firstclass的啊，你放在一个数组里面就好
你想弄的是不是类似lisp marco那样的元编程，那似乎很不利于IDE分析
支持,
也就是标识符(函数名,变量名,常量名,等等)支持非ASCII字符, 支持纯Unicode.
希望关键字也支持中文汉字. 做到统一. 不至于中英文混编.
看不到关键字支持中文的必要。
纯文本代码格式如果不想中英文混编，当下最合适的做法应该是抽出一个别名映射文件（类似typescript的.d.ts之于.ts），然后让IDE在显示层根据需要覆盖统一的英文标识符以及关联对应的文档注释。在这个基础之上，再去扩展IDE的补全功能，使之能补全已加载的中文标识而不需要通过中文输入法键入。
关于必要性补充说明一下，顺便扯点题外话：
就好像以前为什么一些欧美地区在Unicode已经推广开的前提下还在用ASCII和UTF-7一样，资源能省则省，毕竟对他们来说UTF-8平时都用不到。再回过头看MoonBit的需求，它面向的是程序员和AI，对程序员来说，记二十个左右的单词是什么困难吗？显然不是，只有入门阶段的新手需要掌握这个。
说标识符支持Unicode是合理需求，而关键字支持中文是不是等于假设30个英文单词要翻倍成60？那么这时候碰到混编岂不是更头疼。
显示层的问题没必要延伸到底层。我能明白国产编程语言势必会吸引到中文编程爱好者，尤其是有实力的这种，但是MoonBit的定位是要走向国际化的编程语言，那么就应该从大方向来考虑。
很多中文编程爱好者只知道中文对自己有优势，却经常忽略了优势的来源——区域范围内的文字统一（而秦朝的强行统一也加速导致了自我灭亡，这一点同样容易忽视）。
今时今日，相同的情况放到编程语言的i18n问题上大可不必像古时候一样搞强行统一，基于客观事实的推进才是最佳解决办法。目前国际化接受程度最高的语言是英语，那么继续在源码中统一使用英文记录表示程序，是最合适之选。分离出文档注释的覆盖与关键字的映射同属显示层问题，没必要都加到程序源码。
2 个赞
常用 IDE 的中文补全辅助插件 已有这些。
对程序员来说，记二十个左右的单词是什么困难吗？
不那么困难不等于没有更适合的方案。语法设计对代码可读性的影响不可小觑。另外，中文化的设计中，对关键词/语法的本地化仅是一方面。反馈信息等可以一道考虑并先行实现。详请见 MoonBit国产编程语言提供中文关键字的可能性？
@nobodxbodon 既然你提到了IDE插件，那么关键字的问题直接通过插件在显示层替换不行吗？
如果认为fn → 函数 这样只做显示层映射不够完整，要能直接“输入”函数，那么在type ‘函数~<空格>’ 或者 ‘hs<空格><空格>’ 后让插件再转成 fn 不就好了。
代码可读性问题的本质是 “纯文本代码格式” 的可读性问题，只是不凑巧现在大部分的程序逻辑都跟纯文本绑死了，两者不存在直接联系；虚幻引擎的Blueprint它底层没有直接加入类似中文关键字这样的东西，但中文UI下的蓝图照样能用。所以，麻烦建议考虑修改语法关键字的时候先思考必要性，这才是前面我想要说明的。
换个角度，
如果在你实现中文编程理想的路上存在影响代码可读性的敌人，那真正的敌人应该是禁止纯文本以外形式编程的人，而不是反对在纯文本编程语言里加入中文关键字的人。
如果IDE再开放一点，提供docx/pdf/latex那样的富文本排版支持，光是上下标、下划线这两项都足以省去很多关键字了，这时候剩下的也就一个输入效率的问题。输入效率问题受 输入设备、输入法、编辑器 三者的影响（键盘+布局*输入法+IDE），不过目前你在乎的是可读性问题，就这个主题来说，也同样没有展开讨论的必要。
1 个赞
代码可读性问题的本质是 “纯文本代码格式” 的可读性问题，只是不凑巧现在大部分的程序逻辑都跟纯文本绑死了，两者不存在直接联系
编程语言演进了七十年，用”不凑巧“概括有些草率吧。
母语和代码可读性的关系可参考 《 Python3选择支持非ASCII码标识符的缘由》。
关键字的问题直接通过插件在显示层替换不行吗？
如楼上所引回答所言，语法设计仅是本地化的一个方面。个人看来可优先着手的是反馈信息和语法中用到的“术语体系”的整理。
在术语体系一致之前，强行对关键词进行一对一中文化虽然投入不大，但收益亦有限。尤其是原本一些借鉴了英文自然语法的语法设计，一对一的单词中文化可能反而因为语序等让人别扭。反馈信息中文化和术语规整后，再重新设计中文语法不迟，这时还可以连同反馈信息一道考虑以使得两者风格相近。楼主的设计以及无空格等方案都可以考虑。
另有它山之石：《如何看待“抚子”等日语编程语言用于日本中学教学？》