async/await 的，要先知道 foreach 的实现原理

C# 是门很优秀的语言，现在你们能看到的很多语言特性、设计模式，比如 async, Thread, struct, LINQ, GC, prototype extension, CSP(component software programming), COM(component object model), Serialize, Attribute, sealed class, out/ref, message queue, thread pool, generic type, tuple C# 都有，CLR 设计时也有考虑。不得不说单单就语言 research 研究方面 MS 还是很良心的，至少比 Java 特性多，不过性能上可能差一点，毕竟多了很多很多特性。其实 JVM 上的 Kotlin 特性也很多了... 都在往特性多的语言跑

Answer Correct / Accepted
Wrong Answer
Time Limit Exceeded(Error)
Memory Limit Exceeded(Error)
Compile Error
Unknown Error
???
Runtime Error

... 又是一个不教的，非得自己找啊...

国际空间站的业余无线电台举办新一轮的 SSTV（慢扫描电视）活动，该活动将于北京时间 2018 年 10 月 27 日 18:00 左右开始。预计传输将使用 PD-120 模式在 145.800MHz 进行

#recommended #reveng https://github.com/dholm/dotgdb

https://github.com/hellogcc/100-gdb-tips

#PL CovScript (Covariant Scripting Language) 最新的 examples 压缩包

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语法不自由的问题，为入门者提供了更简单的开发环境，为开发者提供了更灵活的开发体验，是目前国内由独立开发者开发的编程语言中功能最完全，综合体验最好的编程语言之一。

[CovScript 最新在线参考文档](http://covscript.org/docs/latest)

感觉老李维护的这个网站 covscript.org 文风有点想当“崇才”的意思，不过是真有技术的，就是文案有点太... 「官方」了

其实老李也算是 C++ 老手了，不说历史，至少你们看上面的 标准程序库囊括了字符串处理，正则表达式，套接字，数据库，图形库，系统API，流式API，关联容器，顺序容器，离散容器，数学运算，随机数引擎，高精度计时器 就知道一定是学后端学成精了（说实话其中 50% 包括离散啊、树状数组啊我还是不知道或者没有彻底理解），看 cs_examples 也能看到不少例子，虽然老李不是没有能力，但 CovScript 的自动内存管理还是基于 shared_ptr 一类的 rc 智能指针的，不是现在流行的 Tracing GC/Rc with Tracing(特指 PHP)，这是毕竟可惜之处了。现在老李上了大学应该会有时间重新设计 CovScript（或者更新实现什么的），所以应该会多加点代码什么的...

InScript 的宏系统还是之前设计 Regular Preprocessor 的时候设计的，后来计划一个 Lua 实现的时候也打算使用，总之就是非常 excited 的基于 token 流处理的宏系统，大概打算来这么玩
宏系统大概也算是为 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
...

不理解 async 函数... 所以这例子举得很差...

不过 Ins 要类型推导也毕竟麻烦，之前模拟的时候说了不支持 Union Type（一个符号可能是两个类型，比如 (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 （准确的说更高级，我们允许在类型之间手动定义转换规则 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)"
... 应该... 不会吧

#zhihu 又忍不住想起那个撕逼 https://www.zhihu.com/question/42315543
话说泛型类型检查写起来也麻烦啊... 要死递归就更麻烦了所以还是简单一点...

最想批判这些不常用缩写从不加含义的人了... 脱口一大堆 terminologies 术语缩写却不告诉大家是啥，弄得我有点把 PLT 当 Procedure Linkage Table（动态链接库符号表） 的意思了... 这么做很酷吗？ #cs #pl

https://www.jianshu.com/p/529b21edd418

看完了之后我发现我有些误解，类型检查不仅是为了 make program compiles 所做的工作，更是为了尽可能确保程序正确做的

王垠比我懂得多，他说 ^ 是“官方”的 「并集类型」intersection type 标记而 | 才是 Type union 的标记

推导出的 int -> int | bool ->bool 表示的确实是一个intersection type，而不是union type。只不过我中间用的|记号跟union type一样，所以看起来比较混淆，然而内部实现确实是intersection type，而不是union type。

现在我把中间的分隔符改成了unicode字符∧，跟intersection type的论文上一样。我想这下他该满意了吧？也就是个表面现象而已。

def ambigous(x):
  return x

a = ambigous(1)
b = ambigous(True)

我怀疑彭飞到底明不明白什么是intersection type。这个type表示这个函数(id)“同时”是int->int和bool->bool，而不是表示它“有时”是int->int，而另外的时候是bool->bool。所以如果你调用id(1)，推导出的输出一定是int。如果你输入id(True)，它推导出的一定是bool。

如果这是一个union type的话，调用id(1)会报错，因为id的类型有可能是bool->bool，不能接受int的输入。调用id(True)也会报错，因为id的类型也有可能是int->int，不能接受bool的输入。所以就左右不是人。

其实如果彭飞仔细看那两个变量a和b的类型，就会发现这是intersection type，而不是union type。

抱歉之前写错了... 我那行 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 } 这种类型推导还是得个垃圾吧