Forwarded from Algae
国际空间站的业余无线电台举办新一轮的 SSTV(慢扫描电视)活动,该活动将于北京时间 2018 年 10 月 27 日 18:00 左右开始。预计传输将使用 PD-120 模式在 145.800MHz 进行
Covariant Script编程语言是李登淳(Michael Lee)于2017年初设计的一门通用型高性能脚本语言,其官方解释器由李登淳本人使用C++编程语言编写。
Covariant Script的目标是成为更加友好的“C With STL”,即综合C编程语言简单明了的语法和C++编程语言强大的标准库,从而最大程度降低语言本身的难度的同时提供强大的功能。
Covariant Script支持大多数主流平台,包括Microsoft Windows,Linux,Mac OS,Android等(Covariant Script理论上能够支持任意提供了标准C++实现的系统中)。用户只需编写一份代码就能够在世界上90%的设备中运行,实现“Write once,run everywhere”。
Covariant Script是动态类型语言,类型这个概念在在Covariant Script中被大大弱化,因此它不需要模板和泛型等特性也能实现灵活的程序设计风格。但因为Covariant Script拥有严谨的类型系统和可靠的垃圾回收器,从而保证了类型安全和资源安全。
Covariant Script的语法融合了C/C++/Java/Lua/Basic等主流编程语言的语法,保留并改造了一部分易于使用的语法,删除了大量难以理解的部分。精简融合的语法仍然保留了现代编程语言的组成要素:模块系统,名称空间,垃圾回收器,异常处理,面向对象编程(OOP),Lambda表达式,基于范围的for循环等。
Covariant Script拥有强大齐全的标准程序库,并为其精心设计了可靠,易于使用的接口和完善的文档。Covariant Script标准程序库囊括了字符串处理,正则表达式,套接字,数据库,图形库,系统API,流式API,关联容器,顺序容器,离散容器,数学运算,随机数引擎,高精度计时器等一系列实用的功能。
得益于优秀的架构和作者丰富的开发经验,Covariant Script非常易于扩展。精心设计的类型系统理论上可支持C/C++中所有的类型,您可能只需定义一些特定的函数即可让您的类型在Covariant Script中自由穿梭。作者为了强化Covariant Script与C++的联系,简化第三方库移植的流程,特意设计编写了CNI(C/C++ Native Interface)。通过CNI Covariant Script将能够直接调用大多数C/C++中的函数(不支持模板函数和重载函数,这是C++语言的限制)。用户无需做太多工作,只需将函数直接注册到Covariant Script中即可,CNI甚至能够自动检测函数签名并适配。
Covariant Script的模块系统分为两部分。一部分是C++编写的扩展,由于脱离了Covariant Script的环境一般来说性能更高,也能够更好的利用底层API。Covariant Script能够动态加载扩展而无须重新编译Covariant Script自身。另外一部分是Covariant Script编写的包,包的特点是更加灵活,依托于Covariant Script跨平台的特性包不需要编译,在不同平台上一般来说是通用的,但性能受语言本身限制不会太高,不适合计算密集或底层的应用。Covariant Script能够在独立于主程序的沙箱中编译解释包并通过模块系统引入到主程序中。
综上所述,Covariant Script是一门全能的编程语言。“麻雀虽小,五脏俱全”,几乎涵盖了计算机程序设计中大多数概念和功能。但它比C++更简单,比C更全能,比Java更轻巧,比Python更灵活。Covariant Script解决了C++语法晦涩难懂,开发环境搭建困难,第三方库安装过程繁冗,跨平台困难;Java运行环境太大以及Python语法不自由的问题,为入门者提供了更简单的开发环境,为开发者提供了更灵活的开发体验,是目前国内由独立开发者开发的编程语言中功能最完全,综合体验最好的编程语言之一。
Covariant Script的目标是成为更加友好的“C With STL”,即综合C编程语言简单明了的语法和C++编程语言强大的标准库,从而最大程度降低语言本身的难度的同时提供强大的功能。
Covariant Script支持大多数主流平台,包括Microsoft Windows,Linux,Mac OS,Android等(Covariant Script理论上能够支持任意提供了标准C++实现的系统中)。用户只需编写一份代码就能够在世界上90%的设备中运行,实现“Write once,run everywhere”。
Covariant Script是动态类型语言,类型这个概念在在Covariant Script中被大大弱化,因此它不需要模板和泛型等特性也能实现灵活的程序设计风格。但因为Covariant Script拥有严谨的类型系统和可靠的垃圾回收器,从而保证了类型安全和资源安全。
Covariant Script的语法融合了C/C++/Java/Lua/Basic等主流编程语言的语法,保留并改造了一部分易于使用的语法,删除了大量难以理解的部分。精简融合的语法仍然保留了现代编程语言的组成要素:模块系统,名称空间,垃圾回收器,异常处理,面向对象编程(OOP),Lambda表达式,基于范围的for循环等。
Covariant Script拥有强大齐全的标准程序库,并为其精心设计了可靠,易于使用的接口和完善的文档。Covariant Script标准程序库囊括了字符串处理,正则表达式,套接字,数据库,图形库,系统API,流式API,关联容器,顺序容器,离散容器,数学运算,随机数引擎,高精度计时器等一系列实用的功能。
得益于优秀的架构和作者丰富的开发经验,Covariant Script非常易于扩展。精心设计的类型系统理论上可支持C/C++中所有的类型,您可能只需定义一些特定的函数即可让您的类型在Covariant Script中自由穿梭。作者为了强化Covariant Script与C++的联系,简化第三方库移植的流程,特意设计编写了CNI(C/C++ Native Interface)。通过CNI Covariant Script将能够直接调用大多数C/C++中的函数(不支持模板函数和重载函数,这是C++语言的限制)。用户无需做太多工作,只需将函数直接注册到Covariant Script中即可,CNI甚至能够自动检测函数签名并适配。
Covariant Script的模块系统分为两部分。一部分是C++编写的扩展,由于脱离了Covariant Script的环境一般来说性能更高,也能够更好的利用底层API。Covariant Script能够动态加载扩展而无须重新编译Covariant Script自身。另外一部分是Covariant Script编写的包,包的特点是更加灵活,依托于Covariant Script跨平台的特性包不需要编译,在不同平台上一般来说是通用的,但性能受语言本身限制不会太高,不适合计算密集或底层的应用。Covariant Script能够在独立于主程序的沙箱中编译解释包并通过模块系统引入到主程序中。
综上所述,Covariant Script是一门全能的编程语言。“麻雀虽小,五脏俱全”,几乎涵盖了计算机程序设计中大多数概念和功能。但它比C++更简单,比C更全能,比Java更轻巧,比Python更灵活。Covariant Script解决了C++语法晦涩难懂,开发环境搭建困难,第三方库安装过程繁冗,跨平台困难;Java运行环境太大以及Python语法不自由的问题,为入门者提供了更简单的开发环境,为开发者提供了更灵活的开发体验,是目前国内由独立开发者开发的编程语言中功能最完全,综合体验最好的编程语言之一。
[CovScript 最新在线参考文档](http://covscript.org/docs/latest)
covscript-docs
参考文档
Covariant Script编程语言:参考文档
其实老李也算是 C++ 老手了,不说历史,至少你们看上面的
标准程序库囊括了字符串处理,正则表达式,套接字,数据库,图形库,系统API,流式API,关联容器,顺序容器,离散容器,数学运算,随机数引擎,高精度计时器 就知道一定是学后端学成精了(说实话其中 50% 包括离散啊、树状数组啊我还是不知道或者没有彻底理解),看 cs_examples 也能看到不少例子,虽然老李不是没有能力,但 CovScript 的自动内存管理还是基于 shared_ptr 一类的 rc 智能指针的,不是现在流行的 Tracing GC/Rc with Tracing(特指 PHP),这是毕竟可惜之处了。现在老李上了大学应该会有时间重新设计 CovScript(或者更新实现什么的),所以应该会多加点代码什么的...InScript 的宏系统还是之前设计 Regular Preprocessor 的时候设计的,后来计划一个 Lua 实现的时候也打算使用,总之就是非常 excited 的基于 token 流处理的宏系统,大概打算来这么玩
宏系统大概也算是为 DSL 做一下扩展而已,实在不行的东西就让代码自己来动态字符串处理好了...
Ins 的「哲学」大概也打算和 Ruby 一样,不要求绝对的性能和正确,不要求整个语言系统有多简单,尽可能追求自然的语法和可扩展性,让 InScript 成为 JVM 上最好的 REPL(好过 Groovy!)。
宏系统大概也算是为 DSL 做一下扩展而已,实在不行的东西就让代码自己来动态字符串处理好了...
macro <name:inline-lanuage> <name>$lang <tokens>$text <keyword:end> = $lang($[text]) 也没打算弄得和 Rust、Crystal 那么复杂还讲宏「卫生」性的啊,一定得展开到有效语法的啊...Ins 的「哲学」大概也打算和 Ruby 一样,不要求绝对的性能和正确,不要求整个语言系统有多简单,尽可能追求自然的语法和可扩展性,让 InScript 成为 JVM 上最好的 REPL(好过 Groovy!)。
# macros.ins
out macro <name:async> <keyword:def> = @async def
out macro <name:await> <tokens>$toks <eostmt> = await -> { $toks }
# async.ins
require "macros"
scope Async
require "async"
using Async
...
duangsuse::Echo
InScript 的宏系统还是之前设计 Regular Preprocessor 的时候设计的,后来计划一个 Lua 实现的时候也打算使用,总之就是非常 excited 的基于 token 流处理的宏系统,大概打算来这么玩 宏系统大概也算是为 DSL 做一下扩展而已,实在不行的东西就让代码自己来动态字符串处理好了... macro <name:inline-lanuage> <name>$lang <tokens>$text <keyword:end> = $lang($[text]) 也没打算弄得和 Rust、Crystal…
不过 Ins 要类型推导也毕竟麻烦,之前模拟的时候说了不支持 Union Type(一个符号可能是两个类型,比如
那么不支持 type union 也就是说一些函数启发式类型推导是不能用的(又是我乱想了...)......
好吧是我瞎想了不支持就是不支持,
(define a (if weather_fine 1 #t)),这里全局符号 a 的类型是 (Number ^ Boolean) ^: XOR)那么不支持 type union 也就是说一些函数启发式类型推导是不能用的(又是我乱想了...)......
好吧是我瞎想了不支持就是不支持,
x => if x { 1 } else { true } 本来类型就是应该推导为 (Integer ^ Boolean) 的,如果不支持推导也就算了,但是支持的话,类型检查器说出它的真实类型也是可以的,但其实 inscript 不支持 safe def 来定义自动推导类型的函数(只能自动推导 var 的类型),所以不存在这个问题...(不过好像还是有,因为我可以选择支持泛型 Block 类型推导,比如 safe block = not_big => if not_big { 1 } else { 1R } 的泛型类型可能是 Block<Boolean ^ BigDecimal> (检查块返回类型)(R 是 Rational,有理数的意思)... 不过啊我不知道别人都是怎么做的...毕竟现在语法添加太多了,不知道会不会出现那种必须到运行时才能 disambiguating(消除歧义)的语法
目前 implicit type cast (准确的说更高级,我们允许在类型之间手动定义转换规则
目前 implicit type cast (准确的说更高级,我们允许在类型之间手动定义转换规则
out def Type.implicitAs out def Type.explicitAs)(out def 是为了保存类型 overload 的信息,单纯 def 会覆盖之前的同名 def(覆盖时如果不使用 new def 语法会收到警告,safe scope 和 safe def 里不允许这么做))是 object as Type 而 -> 被用来赋值 a->prop value_expr
当然 -> 也被用来定义没有参数的 Block 和转换表达式到 Block 类型 ary.each ->println timeout(10) -> println "I love Ruby(x)"
... 应该... 不会吧
duangsuse::Echo
#zhihu 又忍不住想起那个撕逼 https://www.zhihu.com/question/42315543 话说泛型类型检查写起来也麻烦啊... 要死递归就更麻烦了所以还是简单一点...
duangsuse::Echo
不过 Ins 要类型推导也毕竟麻烦,之前模拟的时候说了不支持 Union Type(一个符号可能是两个类型,比如 (define a (if weather_fine 1 #t)),这里全局符号 a 的类型是 (Number ^ Boolean) ^: XOR) 那么不支持 type union 也就是说一些函数启发式类型推导是不能用的(又是我乱想了...)...... 好吧是我瞎想了不支持就是不支持,x => if x { 1 } else { true } 本来类型就是应该推导为 (Integer ^…
https://www.jianshu.com/p/529b21edd418
看完了之后我发现我有些误解,类型检查不仅是为了
王垠比我懂得多,他说
如果这是一个union type的话,调用id(1)会报错,因为id的类型有可能是bool->bool,不能接受int的输入。调用id(True)也会报错,因为id的类型也有可能是int->int,不能接受bool的输入。所以就左右不是人。
其实如果彭飞仔细看那两个变量a和b的类型,就会发现这是intersection type,而不是union type。
看完了之后我发现我有些误解,类型检查不仅是为了
make program compiles 所做的工作,更是为了尽可能确保程序正确做的王垠比我懂得多,他说
^ 是“官方”的 「并集类型」intersection type 标记而 | 才是 Type union 的标记推导出的 int -> int | bool ->bool 表示的确实是一个intersection type,而不是union type。只不过我中间用的|记号跟union type一样,所以看起来比较混淆,然而内部实现确实是intersection type,而不是union type。我怀疑彭飞到底明不明白什么是intersection type。这个type表示这个函数(id)“同时”是int->int和bool->bool,而不是表示它“有时”是int->int,而另外的时候是bool->bool。所以如果你调用id(1),推导出的输出一定是int。如果你输入id(True),它推导出的一定是bool。
现在我把中间的分隔符改成了unicode字符∧,跟intersection type的论文上一样。我想这下他该满意了吧?也就是个表面现象而已。
def ambigous(x):
return x
a = ambigous(1)
b = ambigous(True)
如果这是一个union type的话,调用id(1)会报错,因为id的类型有可能是bool->bool,不能接受int的输入。调用id(True)也会报错,因为id的类型也有可能是int->int,不能接受bool的输入。所以就左右不是人。
其实如果彭飞仔细看那两个变量a和b的类型,就会发现这是intersection type,而不是union type。
简书
到底是谁在欺负我们读书少?
发表了之前的文章《我为什么不再做PL人》之后,我发现有人在知乎上发表文章诬蔑我。本来不想理知乎上的东西,但作者把各种刚从论文上学来的术语,似懂非懂,照本宣科列了一大堆,挺能唬...
duangsuse::Echo
不过 Ins 要类型推导也毕竟麻烦,之前模拟的时候说了不支持 Union Type(一个符号可能是两个类型,比如 (define a (if weather_fine 1 #t)),这里全局符号 a 的类型是 (Number ^ Boolean) ^: XOR) 那么不支持 type union 也就是说一些函数启发式类型推导是不能用的(又是我乱想了...)...... 好吧是我瞎想了不支持就是不支持,x => if x { 1 } else { true } 本来类型就是应该推导为 (Integer ^…
抱歉之前写错了... 我那行
其实是该写成
最后:Ins 的类型推导设置那么多规则甚至用更高级的算法有什么意义呢... 有什么意义呢... 如果常量折叠没有的话
f = x => if x { 1 } else { true } 本来类型就是应该推导为 (Integer ^ Boolean) 的其实是该写成
f 的 「返回类型」是 (Integer ^ Boolean) 或者说 f 的类型是(当然这点输入代码推导不出来它的类型,但假设这是我给它指出的类型) (Boolean -> {Integer | Boolean})
这里写错的 ^ (在你们看是对的,但其实只是歪打正着)被我误解成了是 Type Union 的标记...最后:Ins 的类型推导设置那么多规则甚至用更高级的算法有什么意义呢... 有什么意义呢... 如果常量折叠没有的话
final far safe bo = false; a = if bo { 1 } else { 1R } 这种类型推导还是得个垃圾吧https://www.jianshu.com/p/4149a394ef88 #cs #pl
其实,这个分数的意义远远不止是一个A+,它涵盖的内容可能超乎你的想象。也许你可以从一个很小的例子看出它到底意味着什么。
在课程进行到一半的时候,我花了一个星期的时间,独立解决了曾经困扰程序语言领域十多年的难题——CPS变换。在这十几年里面,有众多的世界级专家参与过这个问题的研究,包括非常强悍的丹麦Aarhus大学教授Olivier Danvy,Andrzej Filinski,Dan Friedman本人以及他的得意门生Matthias Felleisen,Felleisen的得意门生Amr Sabry,普林斯顿大学著名教授Andrew Appel(编译器教材“虎书”的作者)。这些人为这个话题发表了不知道多少论文,Appel还为此专门写了一本书。我之所以会去解决这个问题,是因为Friedman别出心裁,把这个问题作为了一道附加题目放进了B521的作业里。
我不知道这个问题有如此之难,所以愣头愣脑,真把它当成作业题给解决了。按照作业的“道德规范”,完全从问题出发,不看书不看论文不查网络,全凭自己的头脑,在一个星期之内得到了最优的结果。这就是所谓“王垠40行代码”的含义。一个人七天,一群人十年,我想你应该知道这是什么概念。
其实,这个分数的意义远远不止是一个A+,它涵盖的内容可能超乎你的想象。也许你可以从一个很小的例子看出它到底意味着什么。
在课程进行到一半的时候,我花了一个星期的时间,独立解决了曾经困扰程序语言领域十多年的难题——CPS变换。在这十几年里面,有众多的世界级专家参与过这个问题的研究,包括非常强悍的丹麦Aarhus大学教授Olivier Danvy,Andrzej Filinski,Dan Friedman本人以及他的得意门生Matthias Felleisen,Felleisen的得意门生Amr Sabry,普林斯顿大学著名教授Andrew Appel(编译器教材“虎书”的作者)。这些人为这个话题发表了不知道多少论文,Appel还为此专门写了一本书。我之所以会去解决这个问题,是因为Friedman别出心裁,把这个问题作为了一道附加题目放进了B521的作业里。
我不知道这个问题有如此之难,所以愣头愣脑,真把它当成作业题给解决了。按照作业的“道德规范”,完全从问题出发,不看书不看论文不查网络,全凭自己的头脑,在一个星期之内得到了最优的结果。这就是所谓“王垠40行代码”的含义。一个人七天,一群人十年,我想你应该知道这是什么概念。
简书
我为什么在乎这一个A+
我知道有些人至今仍然嘲笑和鄙视我,因为我曾经说过,我在Dan Friedman的两门课程B521(程序语言理论)和B621(高级程序语言理论)都得了A+。只要提到我,他们就会...
#recommended #zhihu
https://www.zhihu.com/question/42016079
我所看到的最佳回答:
其实垠神从来没有黑某个领域,没有黑某个语言,没有黑某个编程思想。
他从来黑的都是像对待宗教一样的盲目崇拜的态度,学者和各个公司里的各种欺世盗名。
他渺小时所崇拜的山峰一样偶像,在他爬上山顶后,轰然倒塌了,他觉得爬山不值,很懊恼。
https://www.zhihu.com/question/42016079
我所看到的最佳回答:
其实垠神从来没有黑某个领域,没有黑某个语言,没有黑某个编程思想。
他从来黑的都是像对待宗教一样的盲目崇拜的态度,学者和各个公司里的各种欺世盗名。
他渺小时所崇拜的山峰一样偶像,在他爬上山顶后,轰然倒塌了,他觉得爬山不值,很懊恼。
Zhihu
如何评价王垠新文章《我为什么不再做PL人》? - 知乎
有问题,上知乎。知乎是中文互联网知名知识分享平台,以「知识连接一切」为愿景,致力于构建一个人人都可以便捷接入的知识分享网络,让人们便捷地与世界分享知识、经验和见解,发现更大的世界。