Closed 4b5ent1 closed 5 years ago
关于非脚本语言也可以类比:
思路也是类似的,编译型貌似只能用haxe那种翻译的思路了,平台型可以转成bytecode。 另外haxe只做翻译可能也是因为考虑到actionscript-转换>c++的问题
和Z语言思路有点类似? Z语言实现基本原理
和Z语言思路有点类似?
@nobodxbodon 还是有点差别的,层级顺序是中文>现有[脚本语言/平台语言]>runtime>编译后的可执行码
不同脚本语言也有各自的特性.而且语言也会更新 如果要把所有的脚本语言的运行时都调度到同一个运行时 而且要实现所有特性的话上工作量太大
@MikaGuraNTK 关于更新的问题,我的想法是以python和node为主,其他少量兼容(比如JVM/.Net CLR)。 不做全覆盖,erlang对应做erlang的port,根据实际需要去推导会好点。 PS:可以类比tidb之于mysql的关系。
换句话说不需要保证方言的一致性,只需在统一文字的基础上,在对应的runtime实现相应的功能就可以。
为了统一,python的核心方言可以锁定版本到3.5.x(为了兼容pypy;3.5以后的作为DLC),node以TypeScript 3.0为准,erlang以OTP21为准,JVM以java8为准(9/10作为DLC),CLR锁定到.net core 2.x就行。
具体语法的话,取erlang、typescript和rust的并集,基本上也就包含了python/.Net/JVM。
今天听说Julia 1.0发布了,感觉很多思路可以借鉴。https://julialang.org/
首先分个类,常见的脚本语言可以这么分:
我觉上述语言,除了erlang/elixir外,都大同小异,甚至很多后端的python代码,都可以直接[机械]翻译成后端的typescript代码。现在的问题在于,PL不互通但可以互译,而相应的runtime却没办法统一调度。我觉得中文编程可以作为上层设计,用来统一调度这些PL的runtime。Haxe那种思路只是把代码从A翻译成B,然后用B去在B的runtime里执行,这种思路感觉还是太原始了,中间层生成了多余的代码,不利于协调。
个人认为合理的调度层次应该是这样:中文化的脚本 -发送给> [middleman代理] -由代理直接操作> runtime