般若编程语言特性的一些探讨

[zhangzhimin]

般若编程语言作为一门新兴的编程语言, 势必会在编程特性上做一些改动, 这里作者对这些改动做一些阐述, 下面的内容会比较主观, 大家要是有不同的看法可以留言一块探讨.

为什么去除了引用

这里引用主要指参数引用传递, 引用变量, 返回引用值构成.

• 首先参数引用不是必须的, 我们不能去改变一个参数, 因为这违背了函数的原则, 引用参数的生存期也得不到保证. 如果非要改变参数, 我们可以传递指针或者将其作为返回值赋值
• 引用变量不是必须的, 也是不推荐的. 我们最好是直接地而不是间接地去操作一个变量.
• 返回引用值不是必须的, Prajna的属性可以更好的处理需要返回引用值的场景.
• 对于编译器优化来说, 目前引用没有任何价值了, llvm也没有相对应的东西.

引用的存在有历史原因, 可能是为了代码优化, 但现在来说其已经是现代编程语言的包袱了, 对于这种价值不大, 并且会导致编程语言复杂和歧义的特性作者是强烈建议移除的.

为什么变量没有只读修饰

const,mutable出现主要可能是两个原因, 一个是为了编译器优化, 另一个是为了程序安全.

• 对于编译优化来说, 目前const对编译器优化来说已经没有什么用了.
• 对于变量来说, 使用const来限制它是属于画蛇添足了, 变量从字面理解就必须可变的, 至于它到底有没有被改变, 代码本身就是最好的描述

所以Prajna里把只读属性的限制去除了.

为什么不提供Private, Protected, Public等修饰符

显然他们不是必须的, 这种非必须的通过注释来修饰会比较好. 编程本身是一个创作和生产的结合, 很多时候我们其实不知道它到底是Private还是Public的.

为什么不提供异常机制

笔者认为最好的异常机制并非各种catch和throw, 而是通过全面的测试来确定你的程序正确. 其实我们做到下面这些事情远远比异常机制有用.

• 使用断言来判断不期望的事件
• 当程序发生错误时候, 马上输出错误信息,然后终止程序.
• 如果错误的状态是程序的一部分, 请使用返回值而不是异常来处理.
• 在使用异常来防止主程序崩溃的地方改用进程隔离来确保主程序的稳定.

上述的建议是根据C++等语言的实践中得出来的, 我们可以看到try-catch-throw的机制并非必须, 大部分情况下也无法理想使用.
因而Prajna直接去除了异常机制, 不过我们仍然会提供断言等一些机制.

为什么引入undef类型

因为比如指向一个内存地址的指针类型, 它是没有一个确定的类型, 这种情况下我们把它定义为undef *会比void *更为合理.

为什么不提供返回值类型推导

因为我们把返回值缺失的情况定为void类型, 这样比较明确. 另一个是现在IDE非常发达, 并不在乎多写一个返回值类型.

为什么不支持部分模板特化

部分模板特化实现比较复杂, 使用时可能存在歧义, 如果存在多个部分模板特化符合规则, 使用者不能清晰知道实例化的到底是那个模板.

为什么不支持模板元编程

每种编程语言都有它的局限于, 不应该为了小众的需求去拓展很多特性. Prajna推荐直接使用IR来实现元编程, 虽然使用会比较繁琐, 但远比模板元编程清晰和强大.

为什么提供属性和下标索引

属性具备读写功能, 在不提供引用的特性的情况下, 是必须提供属性的.

为什么没有模式匹配等特性

大部分时候,我们连switch都很少用到, 搞个模式匹配必要性不大, 并且也难于掌握.

为什么没有函数的前置声明

前置声明目前还没有发现必须场景, 可以引用自身就能处理大部分场景了

为什么内存管理没有采用ownship

首选作者认为Rust使用ownship来管理内存是巨大的设计错误. 本质上Rust的onwship就是C++里的unique_ptr, 它的应用场景是十分有限的, 至少其不能作为一门通用语言的标准内存管理方式.

为什么不提供弱引用

C++中里有weak_ptr的实现, 很多程序语言里也有若引用的概念. 首先弱引用不是必须的, 我们可以把一个ptr置为空来解除引用. 其次弱引用本身违背了引用计数的规则. 笔者认为弱引用机制是一个非常严重的设计错误, 编程语言不应该推荐或者含有这种机制. 首先我们客观认知到循环引用的存在和它存在的合理性, 然后我们再在合适的时间点去解除它.

为什么不提供根引用

Javascript中, 当我们从context不能访问到变量时就会释放该变量. 这种机制并不适合Prajna, 因为Prajna还会和其他语言交互, 并且引用计数会穿透到其他语言甚至穿透到其他进程.

为什么面向对象采用Rust的implement/interface的模式, 而不是C++等的class模式

implement模式更适合大规模程序设计, 因为implement之间相互独立, 模块会比较清晰. 编译器实现上implement是简单清晰很多的, 某种意义上在使用上也会更加清晰. 当然两者之间更多的是个选择问题, 差异未必有很大.