可否支持这种类自然语言编程,像字符串插值一样,让函数方法名都可以使用参数插值,使得参数可以出现在名称的任意地方。

image
我们人类自然语言说话的每个词,串起来每句话的理解,视乎也是一个栈式虚拟机样。

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已经执行!")
}

总感觉变量名用中文来命名有点变扭,中英文混合观感不好。一个汉字看多了,就容易出现视觉疲劳,不认识这个字了。

1 个赞
<火山程序 类型 = "通常" 版本 = 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问题上大可不必像古时候一样搞强行统一,基于客观事实的推进才是最佳解决办法。目前国际化接受程度最高的语言是英语,那么继续在源码中统一使用英文记录表示程序,是最合适之选。分离出文档注释的覆盖与关键字的映射同属显示层问题,没必要都加到程序源码。

1 个赞

常用 IDE 的中文补全辅助插件 已有这些

对程序员来说,记二十个左右的单词是什么困难吗?

不那么困难不等于没有更适合的方案。语法设计对代码可读性的影响不可小觑。另外,中文化的设计中,对关键词/语法的本地化仅是一方面。反馈信息等可以一道考虑并先行实现。详请见 MoonBit国产编程语言提供中文关键字的可能性?

@nobodxbodon 既然你提到了IDE插件,那么关键字的问题直接通过插件在显示层替换不行吗?
如果认为fn函数 这样只做显示层映射不够完整,要能直接“输入”函数,那么在type ‘函数~<空格>’ 或者 ‘hs<空格><空格>’ 后让插件再转成 fn 不就好了。

代码可读性问题的本质是 “纯文本代码格式” 的可读性问题,只是不凑巧现在大部分的程序逻辑都跟纯文本绑死了,两者不存在直接联系;虚幻引擎的Blueprint它底层没有直接加入类似中文关键字这样的东西,但中文UI下的蓝图照样能用。所以,麻烦建议考虑修改语法关键字的时候先思考必要性,这才是前面我想要说明的。

换个角度,

如果在你实现中文编程理想的路上存在影响代码可读性的敌人,那真正的敌人应该是禁止纯文本以外形式编程的人,而不是反对在纯文本编程语言里加入中文关键字的人。

如果IDE再开放一点,提供docx/pdf/latex那样的富文本排版支持,光是上下标、下划线这两项都足以省去很多关键字了,这时候剩下的也就一个输入效率的问题。输入效率问题受 输入设备、输入法、编辑器 三者的影响(键盘+布局*输入法+IDE),不过目前你在乎的是可读性问题,就这个主题来说,也同样没有展开讨论的必要。

1 个赞

代码可读性问题的本质是 “纯文本代码格式” 的可读性问题,只是不凑巧现在大部分的程序逻辑都跟纯文本绑死了,两者不存在直接联系

编程语言演进了七十年,用”不凑巧“概括有些草率吧。

母语和代码可读性的关系可参考 《 Python3选择支持非ASCII码标识符的缘由》。

关键字的问题直接通过插件在显示层替换不行吗?

如楼上所引回答所言,语法设计仅是本地化的一个方面。个人看来可优先着手的是反馈信息和语法中用到的“术语体系”的整理。

在术语体系一致之前,强行对关键词进行一对一中文化虽然投入不大,但收益亦有限。尤其是原本一些借鉴了英文自然语法的语法设计,一对一的单词中文化可能反而因为语序等让人别扭。反馈信息中文化和术语规整后,再重新设计中文语法不迟,这时还可以连同反馈信息一道考虑以使得两者风格相近。楼主的设计以及无空格等方案都可以考虑。

另有它山之石:《如何看待“抚子”等日语编程语言用于日本中学教学?