招募对建设国产语言生态联盟感兴趣的朋友

CovScript 智锐
1

大家好，我是CovScript编程语言的创始人、Main Contributor李登淳(@mikecovlee)。最近我和洛书编程语言的创始人商议，共同建设基于CovScript 3的语言生态联盟，意在减少大家各自维护自己语言生态的成本。目前之所以选择CovScript 3而不是其他语言或VM，是考虑到CovScript 3是自主语言生态，且生态已经比较完善（跨平台、有发行标准、有包管理器、支持Unicode、有配合生态的Parser Generator等）
若有朋友也愿意加入，请在本论坛中留言。我们不仅需要有足够热情和技术的合伙人，还需要一同商议、贡献、测试的志愿者。因为鄙人学业较为紧张，可能无法及时查看，若方便还劳烦各位发个电子邮件到mikecovlee@163.com，我会看到后第一时间回复。感谢！

3 个赞
2

我在这里以Extended CovScript (CovScript 4) 为例，为大家解释一下基于CovScript 3 (简称cs3) 的语言生态未来会是什么样子。
ECS 由两部分组成，分别为编译器和支持库。编译器是基于使用 cs3 编写的 ParserGen 生成的，使用的是类似于 EBNF 的扩展语法规则；支持库是基于 cs3 的 sdk_extension 库 (也就是将部分 CovScript SDK 公开 C++ API 扩展至 CovScript 里) 编写，主要是实现部分 cs3 语言中不存在的语义。
由此一来，ECS 整个便构建在 CovScript 3 之上，虽依赖 CovScript 3，却可以说是更现代、更强大的新一代编程语言。这样的好处显而易见，除了能直接复用 CovScript 3 现有的所有基础设施，反过来 ECS 产生的所有新特性都是对原有生态的一种反哺。
另外一个例子是洛书编程语言。作者非常用心的在做中文编程，我个人说实话是不太能特别认同的，但我也不得不承认中文编程确实能利好一大部分英文水平没那么好的人群，所以一直在和作者有一些私下里的交流。作者就向我指出，很难同时维护多个平台的支持，且包管理器之类的写起来也挺麻烦。这些问题可以通过接入任何一个较为成熟的编程语言实现，但毕竟我手上就有一个还可以的 CovScript 3，便力荐他一起建设这个语言联盟

1 个赞
3

当然，大家也都能看出来很多问题。我这里与大家分享一下语言生态下一步的发展路线：
第一步，在 CovScript 3 的基础上打造 minicov 运行时

  • 裁剪掉大多数 CovScript 3 的语法糖，仅保留最基础的解释器，提高效率、降低体积
  • 裁剪掉大多数 CovScript 3 的内建标准库，仅保留最基础的功能，降低体积
  • 裁剪后对代码进行重构，支持语言级协程
  • 支持引入调试符号，改善代码报错体验
  • 提供统一的 REPL 和调试器后端
4

minicov 本质上还是某种程度上的 CovScript 3 解释器，在二进制层面上兼容现有的所有 CovScript Extension (which is 生态的关键)。因为 ECS 仅不支持少数 CovScript 3 的语法糖，所以只需要使用 ECS 编译器就能直接将原有整个 CovScript 生态迁移至 minicov-runtime

5

未来的目标就是建设一个以 minicov 为核心的语言生态，大家都共同维护这个我们国人自主的动态语言运行时，并根据自己的需求构建各类编程语言到这个生态中，形成类似 JVM 生态的新国产生态。
当然，还有一个问题是为什么不搞虚拟机，一个是 Bytecode 标准难以制定，另一个是代码生成难度显著较高，为了降低门槛吧。不排除未来会为 minicov 增加字节码前端，这样便和 VM 无异了。

6

支持。
希望早日看到更多介绍文章，比如前后端之间的接口设计，以及语法定制方法和报错等反馈机制。
看到裁剪和最小化，感觉挺好，有点微服务的味道。个人觉得今后语言可能会同时使用超过一个后端，以取各语言功能之长，比如要添加推导功能可以加上 Aya 等作为后端，详见之前 向千里冰封的咨询

7

当前进度：

  • 语言级协程(STD210506 引入)
  • cSYM 调试符号(v3.4.2 Build 15 引入)

计划中：

  • 解释器从 STDIN 直接读取代码内容 (v3.4.2)
  • 支持 cSYM 的调试器 (v3.4.2)
  • Unicode 纳入语言标准和标准库 (v3.4.3, STD210507)
  • 解释器和调试器的本地化 (v3.4.3)
  • ParserGen 引入 EBNF 支持
8

当前进度：

  • 解释器从 STDIN 直接读取代码内容 (v3.4.2 Build 16 引入)
  • 支持 cSYM 的调试器 (v3.4.2 Build 18 引入)

开始准备 3.4.2 版本的测试和发行工作了

9

假如某天要将像 木兰 这样基于 python 生态的语言改用智锐后端，不知可以做到继续使用 python 第三方库吗？

10

肯定是没有原生支持的，Python 和 Cov 的对象模型差距太大，很难做直接的 FFI
但可以用 CFFI 直接去调用，但这样会很麻烦，效率也不高

1 个赞