D# 语法

时间 2019-11-18

标签语法繁體版

原文原文链接

这篇文章随意的记录关于 D# 语法的想法。javascript

有关 ILBC / D# ，见《ILBC 白皮书》 http://www.javashuo.com/article/p-bsuuysoc-bo.html 。html

D# 又名 Data ， D++ 。前端

D# 支持结构体方法和继承， D# 的结构体的静态方法和类同样，实例方法所有采用扩展方法的方式定义。java

扩展方法就是 C# 里的扩展方法的那种扩展方法。git

在一个静态方法的第一个参数传入结构体自身，这就是实例方法。程序员

D# 结构体实例方法的定义比 C# 扩展方法简单，不须要在第一个自身参数前加 “this” 关键字。github

好比， A 结构体，数据库

struct A编程

{json

public static void Foo( A a )

{

// do something

}

能够这样调用：

A a;

……

a.Foo();

还能够经过指针的方式传递自身参数，好比：

struct A

{

int i;

public static void Foo( A * a )

{

int j = a -> i ;

// do something

}

能够这样调用：

A a;

( & a ) -> Foo() ;

或者：

A * a;

a -> Foo() ;

嘿嘿嘿，指针的方式能够用于体积比较大的结构体。总之 D# 提供了灵活性。

更灵活的是， D# 容许结构体同时定义按值传递和按指针传递 2 个重载的实例方法，就是：

struct A

{

int i;

public static void Foo( A a )

{

// do something

}

public static void Foo( A * a )

{

int j = a -> i ;

// do something

}

能够看到， Foo( A a ) 和 Foo( A * a ) 能够共存，是重载。

固然，指针操做是 unsafe 操做，全部的指针操做都应该用 unsafe 关键字修饰，因此上述代码应该加上 unsafe 关键字，以下：

struct A

{

int i;

public static void Foo( A a )

{

// do something

}

unsafe public static void Foo( A * a )

{

int j = a -> i ;

// do something

}

看，在 Foo( A * a ) 前面加上了 unsafe 关键字，对于 C# ， unsafe 代码应包括在 unsafe 块中，

D# 简化了这个作法，不使用 unsafe 块，而是用 unsafe 关键字修饰方法，

也能够修饰类，修饰类表示整个类都是 unsafe，就不须要每一个方法都用 unsafe 修饰。

unsafe 没有实际意义，只有标记意义。

unsafe 的做用就是能够经过编译器查找全部的 unsafe 方法类，让程序员能够容易的关注 unsafe 代码。

为何要支持结构体和 unsafe ？由于我以前在《ILBC 规范》中说过， D# 的设计目标之一是执行效率。

具体的说， D# 的结构体和 unsafe 主要会用来支持底层应用，基础应用，高性能中间件。

除了进程（线程）调度、 IO 内核模块之外，包括套接字（Socket）在内的底层模块均可以用 D# 编写。

事实上只要不使用堆（new）的话，进程（线程）调度、 IO 内核模块也能够用 D# 编写，

这种状况基本上所有是 unsafe 代码和结构体，这种状况差很少和 C 等价。

但这样的话，好像还要加一个 “开关”，好比编译选项什么的，在 “不使用堆的模式下” 编程（编译）。

这会让一个语言变得复杂，不太符合 D# 的初衷。

实际上进程（线程）调度、 IO 内核模块这就是 C 的事，不必去和 C 抢。呵呵呵呵。

C++ 就是那种 “只要你选择，什么均可以作” 的语言，因而呵呵了。

这就好像有的业务系统写的很灵活，什么均可以作，只要你去配置，，，，，，

而后，灵活过头了，一堆配置，等你学会这堆配置，也差很少成这个系统的专家了。问题是这个系统的专家只是在你的公司里有用，外面的业界对此没什么承认，而后就呵呵了。

那什么是基础应用呢？好比图形图像，2D 3D，游戏，视频音频，视频采样，音频采样，人工智能，大数据，数据库，文档数据库，大规模并行计算文档数据库，搜索引擎，爬虫，编译器，文本编辑器，大型文本编辑器，，，

什么事高性能中间件？好比 Nginx ，上面基础应用中提到的文档数据库之类好像也能够算中间件。还有搜索引擎也算中间件？不知道 ……

结构体由于没有 GC ，因此难以应用于对象图（结构体引用图），可是单纯在栈中的结构体的应用范围也颇有限。

可是，有一种场合，结构体能够获得充分的使用，就是结构体数组，

或者说，一个很大的数组中包含了不少的结构体。

这在基础应用中很普遍，

好比上面说的图形图像，2D 3D，游戏，视频音频，视频采样，音频采样，，，，，，，

乃至于人工智能，大数据，数据库，文档数据库，大规模并行计算文档数据库，搜索引擎，爬虫，编译器，文本编辑器，大型文本编辑器都与此有关。

D# 对结构体和指针的支持很是适合于这些场景。

数组自己是属于堆的，可是数组里包含了大量的结构体。

基础应用须要对这种场景很是良好的支持。

因此从这里能够看到， D# 的意义之一，开发基础应用不必定要用 C++ ，如今的情况就是基本都用 C++ 。

包括图形图像视频音频人工智能。

因此 D# 须要对数组进行比较大力的支持，包括排序等，其它的还有什么？想不出来，你们想到能够告诉我。

C# 对集合类好比 List<T> 的支持不少，我也不太清楚，反正有不少方法和扩展方法。

不过 D# 首要支持的是数组，别跟我说什么 List<T> ， C# 都在推 Span, ArraySegment 了，

D# 没有那么多麻烦，直接数组。

从 C# 的 Span, ArraySegment, ArrayPool, BufferManager 这一堆东西能够看出来， C# 目前的尴尬。

这一堆东西每个都是一套复杂的班子，我又想起前几天我查了一下 C# 的元组，其实我须要的只是 ( int i , string s ) 这样一个小括号而已，

结果查出了一大堆名字空间很长的东西，里面好像有 “Tuple” 字样，又是泛型，又是继承，好像 Visual Studio 还要装什么安装包，

而后。

呀，我怎么不知不觉的又批评 C# 一下了？

D# 对于数组的操做好比排序什么的，能够在指定的范围（Range）内进行，好比数组有 1000 个元素，我只对第 200 ~ 400 个元素排序，这只须要在调用 Sort() 方法时指定开始 index 和结束 index 就能够了，好比：

int [] iArr ;

……

iAr.Sort( 200 , 400 ) ;

若是实在要封装，本身弄个结构体或者对象把开始 index 和结束 index 包装起来就行，好比：

struct Span

{

int beginIndex,

int endIndex

}

void Foo( Span span )

{

int [] iArr ;

……

iAr.Sort( span.beginIndex , span.endIndex ) ;

}

面向对象爱好者们可能喜欢把 Sort() 也封装到 Span 里，

class ArraySpan<T>

{

private T [] arr ;

private int beginIndex ;

private int endIndex ;

public ArraySpan(T [] arr, int beginIndex, int endIndex)

{

this.arr = arr;

this.beginIndex = beginIndex ;

this.endIndex = endIndex ;

}

public Sort()

{

this.arr.Sort( this.beginIndex, this.endIndex ) ;

}

这也能够，不过这是程序员的事，不是语言的事，或者说这是库的事，程序员能够把本身的封装贡献出来，做为库。

另外一方面， List<T> 固然也要，不只 List，还有 Dictionary, Queue, LiinkedList, Stack 这些都要， D# 固然也要有一个 System.Collections 。

不过大量数据的存储操做仍然是数组。

能够用 List 来存放多个数组。

通过一番思索（过程略），我决定这样来设计 D# 的数组：

D# 有 2 种数组， unsafe 数组和托管数组， unsafe 数组也叫原生数组，就是一个 C 语言数组，也能够说是数组首地址，或者指向某个元素的指针，

托管数组是一个对象，内部包含了一个 unsafe 数组，注意，重点来了，

托管数组是用泛型实现的，托管数组是一个泛型类，

这样，对于多维数组，咱们须要像 C# 的 Action 同样，预先定义好多个数组类型，

就像 C# 的 Action 有这些定义：

Action, Action<T>, Action<T1, T2>, Action<T1, T2, T3>, Action<T1, T2, T3, T4> , ……

D# 的会定义这些数组类型：

Array1<T>, Array2<T>, Array3<T>, Array4<T>, Array5<T>, ……

Array1 是一维数组， Array2 是二维数组， Array3 是三维数组， ……

D# 容许给索引器（中括号 [ ] 经过逗号隔开传入多个参数），

好比

Array2<int> iArr = new Array2<int>() ;

iArr [ 2, 3 ] = 10 ;

这样的话，实际上，程序员彻底能够本身来实现托管数组，能够自由的实现 n 维的托管数组，

也就是说，托管数组不是语言的事，是库的事，程序员能够自由的实现托管数组，能够把本身实现贡献出来，做为库。

社区里能够有多种托管数组的实现（库），程序员能够任意选择使用，更能够本身实现贡献。

这就是 “库” 的理念。

这是一种简洁开放的语言理念。

固然， unsafe 数组由 D# 提供。

这样的作法有点可笑，可是很爽。

咱们再回过头来看看 C# 的数组， C# 有一个 Array 类，内部作了不少工做，可是这些工做程序员很难了解，也不能参与，这就是 C# 常常挥舞的 ”CLR 技术“ 。

咱们再来看看数组的方法，好比 Sort() 方法，咱们以一维数组为例，为何要以一维数组为例，由于多维数组的排序说不清楚，，固然，你能够去实现你本身的多维数组，包括排序。

排序中会对元素进行比较运算，对于基础类型，好比 int float double，比较运算就是 > < == != >= <= 运算符的运算，

可是，为了复用代码， Array1<T> 但愿对于全部的 T 类型都可以用同一个 Sort() 方法，这就须要全部的 T 类型都支持 > < == != >= <= 运算符的运算，

这就涉及到运算符重载。

也能够不用运算符重载，而用 C# 里的 Comparer 的方式，给 Sort( IComparer comparer ) 方法传一个 Comparer 对象，

可是，对于基础类型（int float double char 等）来讲，调用 Comparer 的方法比较大小比起用 > < == != >= <= 运算符会带来一些性能损耗。

为了保持基础类型的原生效率，因此须要运算符重载。

能够声明这样一个 Template ：

template TCompareOperator <T>

{

bool operator = ( T val1, T val2 ) ;

bool operator > ( T val1, T val2 ) ;

bool operator < ( T val1, T val2 ) ;

bool operator >= ( T val1, T val2 ) ;

bool operator <= ( T val1, T val2 ) ;

bool operator != ( T val1, T val2 ) ;

}

而后，把 TCompareOperator 做为数组的泛型约束，

好比，

class Array1<TCompareOperator T>

{

……

public void Sort()

{

……

}

可是这样的话， Array1 的元素类型只能是实现了 TCompareOperator 的类型。这就有了局限，

能够把 Array1 的名字改为 SortableArray1 ，哈哈哈哈。

若是要让元素仍然支持全部类型的话，能够把 Sort() 方法变成一个静态方法，

public static void Sort< TCompareOperator T >( Array1<T> arr )

Template 是仅用于值类型的，值类型包括基础类型（int float double char 等）和结构体，

Interface 则用于引用类型（对象），

为了让 Sort() 方法支持值类型和引用类型的元素，还须要给泛型约束加上引用类型的泛型约束：

public static void Sort< TCompareOperator ICompareOperator T >( Array1<T> arr )

ICompareOperator 是一个实现了 > < == != >= <= 运算符重载的 interface ，

除了 interface，基类也能够做为引用类型的泛型约束，就是说，基类和 Interface 均可以做为引用类型的泛型约束。

结构体自己应该也能做为结构体的泛型约束，这表示这种结构体和它的子类结构体能够做为泛型参数。

问题是结构体能够继承，可是不能多态，因此要注意子类结构体实际上被调用的方法是哪一个。

结构体的继承纯粹是为了复用代码，子类结构体不能 override 基类结构体的方法，可是能够用 new 覆盖，

子类结构体的值和指针不能赋值给基类结构体的变量和指针变量。

注意， interface 这里只做为约束，不会使用多态，由于具体类型会经过泛型参数 T 指定，因此， Sort() 方法中对于 T 对象的方法调用仍然是静态编译时决定的，和普通的调用对象方法是同样的。

除非是 A 类实现了 I1 和 I2 两个接口，这两个接口有同签名方法 Foo()，而 Sort() 方法中须要调用 Foo()，

这种状况就要看 C# 中对于这样的状况会不会报错：

A a = new A() ;

a.Foo() ;

A 类对 I1 I2 两个接口的同签名方法 Foo() 分别进行了显式实现，那么在 C# 中上述 a.Foo() 代码会不会报错？

若是不报错，那调用的 Foo() 方法是哪一个接口的实现？

等，咱们在说 D# ，怎么说到 C# 了？没错，就是说 C#，看看 C# 怎么处理这种状况，

若是会报错，那么对于 D# ，能够先把 a 对象转型为要调用 Foo() 方法的那个接口类型，好比 I1 a1 = (I1)a ; ，再传给泛型方法，

好比，有个方法 void Hello< I1 T >() ，那么，

A a = new A() ;

I1 a1 = (I1)a ;

Hello<I1>( a1 ) ; // 这里将 T 声明为 I1，若是不是这种显式实现多接口同签名方法状况的话

看 Hello<I1>( a1 ) ; ，这里将 T 声明为 I1，若是不是这种显式实现多接口同签名方法状况的话，应该是

Hello<A>(a) ; 将 T 声明为 A，

而将 T 声明为 I1，意味着泛型方法中对 a.Foo() 方法的调用就是使用了多态。

多态的话，会在向上转型 (I1)a 时会查找虚函数表，这是查找一个 Hash 表，因此多态比普通方法调用会多这么一个性能损耗，固然找到虚函数表后，还要在虚函数表中查找函数指针，这里会比普通方法的动态连接多做一个加法，固然这个加法的性能开销基本能够忽略。

因此，可以不使用多态的话，就不要使用多态，固然这是说这里指定泛型参数 T 的场合，不是说其它场合，否则的话面向对象爱好者可能会生气的。^^

固然，从上面举例能够看到，指定泛型参数通常状况均可以直接指定具体类型 A ，只有 A 实现了 2 个或多个 interface，这些 interface 又有同签名的方法，A 对这些同签名方法显式实现的状况才会须要将 A 向上转型为 interface，而后指定泛型参数 T 为 interface 。

好吧，其实不用这样，就算显式实现多接口同签名方法，其实也不用向上转型，仍是

Hello<A>(a) ;

就能够，咱们看方法定义：

void Hello< I1 T >()

这里的 T 的约束是 I1 ，编译器能够据此推断出应该调用 A 实现 I1 的 Foo() 方法，因此仍然在静态编译时就能够决定调用 A 显式实现 I1 的 Foo() 方法。

啊哈哈，其实上面主要是把问题分析一下，而且把 D# 实现多态的原理再梳理一下。

另外，还引出一个问题， Array.Sort() 方法

public static void Sort< TCompareOperator ICompareOperator T >( Array1<T> arr )

若是要对参数 arr 像上面说的那样向上转型的话，就不是 I1 a1 = (I1) a ;

而是

Array1<A> arr = new Array1<A>( 10 ) ; // 参数 10 是数组长度

Array1<I1> arr1 = ( Array1<I1> ) arr ;

这就是 Array1<A> 向上转型为 Array1<I1> 的问题了，至关于 C# 里的 A [ ] 转 I1 [ ]，或者 List<A> 转 List<I1> ，

C# 里好像不容许这样转，但我想 D# 应该容许。 ~~~

为了让 Sort() 方法支持基础类型和自定义结构体，基础类型固然会内置标记为实现了 TCompareOperator 。

虽然标记了实现 TCompareOperator ，可是基础类型和自定义结构体运算符重载的实现方式是不同的，

基础类型是原生的 C 的运算符运算，而结构体的运算符重载是一个函数调用。

说到函数调用，会想起内联，别跟我说内联，我不太打算在 D# 里支持内联，

内联是个复杂的东东，是个麻烦事，

另外， D# 的第一目标是保持基础类型的原生效率，至于自定义类型（包括结构体和对象），调用函数的性能损耗不算什么。

而现代 CPU 架构的寄存器愈来愈大，因此函数调用入栈出栈传参返回值的开销应该愈来愈稀释。

这是运算符重载的方式，上面说了，还能够有 IComparer 的方式，

好比，声明一个 IComparer< T> 接口：

interface IComparer<T>

{

CompareResult Compare( T val1 , T val2 ) ;

}

enum CompareResult

{

Greater,

Less,

Equal

}

Sort() 方法声明为

class Array1<T>

{

public void Sort( IComparer<T> comparer )

{

……

}

能够看到， IComparer<T> 的 T 是由 Array1<T> 的 T 决定的，好比：

Array1<int> iArr = new Array1<int>() ;

那么，传给 Sort() 方法的 IComparer 对象应该是 IComparer<int> 类型。

基础类型也能够用 IComparer 的方式，用 IComparer 方式的话，比较就是一次函数调用，对基础类型来讲，效率比直接用运算符的方式低一点。

进一步，还要解决一个问题，就是按值传递和按指针传递的结构体在泛型时调用方法的语法统一问题。

好比，咱们写一个 Hash 表，

class HashTable<THash Object TKey, TValue>

{

public void Add( TKey key, TValue value )

{

int hash = key.GetHashCode() ;

……

}

能够看到，在 Add() 方法中，会调用 key.GetHashCode() 方法来计算 key 的 hash 值，

TKey 的泛型约束是 THash Object， Object 是有 GetHashCode() 方法的， THash 也有 GetHashCode() 方法，咱们来看看 THash 的定义：

template THash

{

int GetHashCode() ;

}

咱们定义 2 个结构体， A 、B ：

struct A : THash

{

public int GetHashCode( A a )

{

……

}

struct B : THash

{

public int GetHashCode( B * b )

{

……

}

A B 都实现了 THash 的 GetHashCode() 方法， A 实现的是按值传递的方式， B 实现的是按指针传递的方式，

按值传递和按指针传递可任选一种，只要实现了一种就算实现了 template 的方法，固然， 2 种都实现也能够。

那么，问题来了，对于按指针传递的方式，好比

HashTable < B *, string > ht = new HashTable < B *, string >() ;

此时，泛型生成的具体类型是：

class HashTable~1

{

public void Add( B * key, string value )

{

int hash = key.GetHashCode() ;

……

}

能够看到， Add() 方法中计算 hash 值的代码是

int hash = key.GetHashCode() ;

key 是 B * 类型，这里应该是 key -> GetHashCode() ; 而不是 key.GetHashCode() ; ，这样就出问题了。

那怎么解决这个问题？我提出了 .-> 操做符，就是把 . 和 -> 两个操做符结合到一块儿。

.-> 操做符只能用于泛型类和泛型方法内的代码以及只能用于结构体和结构体指针类型。当使用 .-> 操做符时，编译器会判断变量是结构体仍是结构体指针，若是是结构体，则按 . 操做符处理，若是是结构体指针，则按 -> 操做符处理。

结构体指针是指结构体的一阶指针，即 B * ，只有一个星号的指针，若是是二阶或多阶指针，好比 B * * , B * * * ，这种 “指针的指针”，则编译器会报错。

这样就很好的实现了对结构体的支持，这很重要，这意味着 D# 能够支持高性能的底层代码，这能够有效的支持 D# 应用于底层模块、基础应用、高性能中间件、游戏。 C++ 的不少应用场合 D# 都能胜任。 D# 又叫 D++ 。

D# 判断是不是 unsafe 代码的标准是是否使用了指针，使用了指针就是 unsafe，不使用指针就不是 unsafe 。

D# 鼓励使用 unsafe 代码。

在底层模块、基础应用、高性能中间件、游戏里都须要大量使用 unsafe 代码。不须要也不提倡使用 unsafe 代码的是业务系统，可是业务系统使用的各类基础库内部应该是 unsafe 代码实现的，好比集合（List, Dictionary, Queue, Stack, LinkedList 等）、 Socket 、 IO（File 等）等等。

还有第三方库，事实上基础库和第三方库没有明显的界限，上面说了， D# 开放的 “库” 的理念，任何人均可以为 D# / ILBC 写库，

咱们能够在必定共识的基础上，把某些库称为 “标准库”，但这也能够不是必定的，你搞一个 “A 标准库”，别人还能够搞一个 “B 标准库”，还能够有 “C 标准库” 、 “D 标准库” ……

总之想怎么玩均可以。

咱们能够再来概括一下结构体的几种数据模型：

1 栈内结构体，

2 数组内的结构体，数组属于堆，数组能够包含大量海量的结构体，

3 数组堆

为了对第 1 种模型，栈内的结构体更好的支持，还能够提供动态分配栈空间的特性。

那第 3 种模型数组堆又是什么？ “数组堆” 这个名字我是想出来的，也不必定很贴切。就是一次申请一个很大的 byte 数组，而后在这个数组里来分配空间，这样就不用每次须要分配内存都要经过堆。

这种作法在 C++ 里也许叫作 “内存池” 。

想到数组堆是由于上面说基础应用的时候提到编译器，我想早期的编译器可能会申请一个比较大的 byte 数组，而后把生成的语法成员树保存在这个 byte 数组里，每一个语法成员是一个结构体，每次能够为这个结构体在数组里分配一段空间，把结构体保存在这个数组的一段空间里。

只须要有一个变量 p 保存剩余空间的首地址就能够了，每次分配后， p 的值加上分配的空间大小，即 p += 分配的 Size ; ，

这有点相似栈， p 就至关于栈顶，等，，，，好像就是栈。

这和堆的区别和优势是，数组堆的分配很是快，就是 p += 分配的 Size ; 这样一个加法和赋值运算。并且没有堆的碎片问题，包括从碎片（空闲空间）中寻找最接近分配大小的碎片来分配的问题，以及从碎片中分配后产生新的碎片等等复杂的堆管理问题。

固然，相对的，数组堆就没有堆那么灵活。由于数组堆回收空间一般时整个数组所有回收，也就是 p = 数组首地址 ; ，

能够在一个任务或者请求内使用数组堆，好比每次编译使用一个数组堆，编译的结果（语法成员树）就存放在这个数组堆里，编译过程中产生的表示字符数组段的 Span 结构体也能够放在数组堆里，固然能够放在另外一个数组堆，语法成员和 Span 各自使用一个数组堆。这样每次编译 2 个数组堆搞定。

若是涉及到并发，即多个任务 / 请求 / 线程之间须要共享数据，那共享数据不适合用数组堆，应该直接使用堆。

大概是这样。

不考虑并发的话，就不须要有 lock，这样，从数组堆里分配就是一个加法赋值 p += 分配的 Size ; ，清空数组堆就是一个赋值 p = 数组首地址 ; ，这个速度比起堆的分配和回收，简直快到飞起。

接下来该说什么了？说说 Attribute，说实在的，真不想在 D# 里支持 Attribute，这会让编译器变得复杂，另外，我是个没有耐心的人，宏伟计划要作的事愈来愈多不免让人心烦。

Attribute 在开发实践中最大的用处大概是 ORM，用于描述数据库表 - 类列 - 属性的对应关系。对于 D# 而言， Attribute 最大的用处是 [ DllImport( ) ] Attribute ，这个用于描述对外部库函数的调用，这很重要。

调用外部库是 ILBC / D# 的一个核心特性模块基因。

用 Attribute 描述外部库函数确实很方便，比关键字的描述能力强不少，并且不须要语言增长关键字来支持。

.Net / C# 内部用 Attribute 倒用的很嗨，不少与开发者无关的 JIT / CLR 特性都是用 Attribute 描述的。

可是咱们再看看 Ruby 和 Javascript ， Ruby 有 Attribute 吗？ Ruby on Rail 好像玩的很溜， Javascript 有 Attribute 吗？ Javascript 的动态特性是最吸引人的一个特性。

不过总的来讲， Attribute 好像仍是得支持一下，毕竟一个完备的元数据体系仍是须要的。

支持 Attribute 也不难，编译器加入对 Attribute 的支持也能够保持架构的简洁，这问题不大， ILBC Runtime 对 Attribute 的支持也不难，就是个工做量的问题，由于 ILBC 原本就有元数据系统，这是动态连接和反射的基础， ILBC 动态连接自己就是基于反射的，反射基于 Hash 表查找，固然 Hash 表和链表能够共存，就是说成员（类字段方法）同时保存在 Hash 表和链表里， Hash 表用于按名字查找，链表用于遍历。

Attribute 只不过是本来类字段方法的元数据上增长一些属性，或者说增长一个属性集合。

再来看看 StackTrace，说实在的， StackTrace 我也不想支持，支持 StackTrace 是个麻烦事，估计要作比较多的工做，虽然提及来两句话就能说清楚，好比 “在编译的时候在每一个方法调用的时候生成一段代码用于记录 StackTrace” ，提及来简单，但估计也很烦，主要是咱们没有那么多时间和精力，这很容易分散咱们的时间和精力。

并且，能够看到， StackTrace 会在函数调用时作一些额外的工做，因此是会产生性能损耗的。

可是，若是不支持 StackTrace，会不会像 C / C++ 那样太原始太裸？

不过咱们看看 Chrome 里的 javascript 报错时有没有 StackTrace ？若是没有，那 D# 也能够没有。 ^^

ILBC / D# 应该是一个能够像脚本同样容易的使用的 AOT / Native 语言平台。就像 Python , Javascript 。固然 ILBC 是 AOT / Native 的。

可是从使用上来讲， ILBC / D# 应该能够像脚本同样容易的使用，就像 Python , Javascript 。

固然，你能够用 ILBC / D# 开发出各类类型和风格的语言，好比 AOT， JIT 脚本，面向对象，函数式等等。

D# 应该用动态编译 D# 代码取代 C# 的 Emit 和表达式树。

C# 的 Emit 和 Expression 是笨重的堆砌。

协程是 ILBC / D# 的一个核心特性模块基因。

有关协程，见《协程的实现方法》 http://www.javashuo.com/article/p-vojdpflm-be.html 。

再谈谈调试的问题，调试，是 IDE 的部分，做为一个开放自由有生命力的语言平台，是不该该依赖于 IDE 的，

咱们欢迎 IDE 提供好的支持，可是语言平台不该该依赖于 IDE 。

看看宇宙第一 IDE 和 C# 的关系就知道了，离开 Visual Studio ，怎么开发 .Net 程序？这不可想象。

这不只仅是对 C# 语法的语法错误和智能提示的支持，还包括对具体的程序项目的支持，

好比， WinForm 程序，没有 Visual Studio ，你怎么写？

Asp.net 程序，没有 Visual Studio ，你怎么写？

并且 Visual Studio 的 WinForm , Asp.net 项目拿给 VsCode 是不能直接编译的，这是我猜的，由于我没怎么用过 VsCode 。

这些现象，表示这不是程序员要的 “理想国” 。

ILBC 要实现的，是一个用记事本也能写程序的语言平台，这是程序员的理想国。

这其实很简单，咱们只须要一些简单的规则就能够实现，好比，最简单的，编译器是一个命令，咱们能够告诉编译器一个路径，这个路径就是项目的根目录，编译器会寻找这个目录和全部的子目录里的源代码文件进行编译，那么对于 Bin 目录，或者资源目录等等一些咱们须要编译器忽略的目录怎么办？

能够相似 Git，在项目目录下放一个 ilbc_src.ignore 的文件，里面声明须要忽略的目录，就能够了。

甚至，能够比 Git 还简单， ilbc_src.ignore 只容许声明项目目录下的第一级子目录，这样就太简单了。

实际上，这也够用了。

编译器对项目目录下的源文件编译，会把全部的错误都在控制台里列出来，哪一个位置是什么错，这和 Visual Studio 或者其它 IDE 是同样的。

对于像 WPF， Asp.net 这种类型的项目，有 Xml 格式的前端代码（文件），这也没问题，你能够用 Xml 编辑器来写前端代码（文件），固然，用记事本也能够。 ^^

而后，编译器一样对项目目录下全部的源代码文件，包括前端文件和后端文件进行编译，并显示全部错误。

因此，无论后端代码仍是前端代码，你能够选择任意的文本编辑器来编写，而后交给编译器来编译。

你也能够根据上述规则开发一个 IDE ，这均可以。

你的项目拿给别人，别人能够用本身的文本编辑器和编译器来继续开发和编译，也能够用 IDE 。

在这方面， Chrome 彷佛干的不错，你能够用任意的文本编辑器写 Javascript，而后 Chrome 的 DevTools 可让你很方便的调试程序。

相比之下， Visual Studio 在不一样版本间都可能不支持互相打开项目。

等，咱们是说调试的，怎么说着说着就跑题了？调试是一个麻烦事，原理大概是这样：

首先，要调用一个操做系统提供的 API “附加进程”，调用了这个 API 就能够把系统的调试器附加到要调试的进程，以后进程每执行一条指令大概都会发起一个中断，系统会在这个中断里调用咱们的处理程序，咱们的处理程序能够知道当前是在执行第几行的反汇编代码，根据汇编代码的行数和指令去 “符号表” 中寻找这一行对应的源代码是哪一行，而且指令也要和符号表中对应的源代码行的指令符合，这样就能够单步调试了。

符号表就是好比 .Net 里的 pdb 文件，在编译时会生成汇编代码和源代码的对照表，这个对照表就是符号表。

固然，以上这些是我猜的。

这些实际上作起来很麻烦，并且这些是最基本，通常调试除了单步调试，还有 Step Over Function, Step Out Function, 直接运行到下一个断点，还有查看局部变量全局变量。

因此，我建议，没必要将精力放在实现调试上，可是，应该提供控制台输出的支持。

控制台输出是最古老的调试方式，也是永不过期的调试方法。

数组堆

template interface

值类型结构体结构体方法，传值，传指针，泛型，数组，集合类泛型， .-> 操做符， > < >= <= == 运算符重载， Comparer，

栈结构体，对象图，

底层应用，基础应用，图形图像，2D 3D，游戏，视频音频，视频采样，音频采样，人工智能，大数据，数据库，文档数据库，大规模并行计算文档数据库，搜索引擎，爬虫，编译器，文本编辑器，大型文本编辑器。

Attribute，

调用外部库是 ILBC / D# 的一个核心特性模块基因。

StackTrace，

ILBC / D# 应该是一个能够像脚本同样容易的使用的 AOT / Native 语言平台。

固然，你能够用 ILBC / D# 开发出各类类型和风格的语言，好比 AOT JIT 脚本，面向对象，函数式等等。

D# 用动态编译 D# 代码取代 C# 的 Emit 和表达式树。

调试

ILBC 源代码项目规范

协程是 ILBC / D# 的一个核心特性模块基因。

template 和 interface 同时做为一等公民

D# 是程序员的语言，不须要太多包装和修饰，

D# 是简单的，编译器和 IDE 都是，程序员的语言是简单的

let ，相似 js 的 let，用以支持完备的闭包特性，通常的变量至关于 js 的 var ，加上 let 至关于 js 的 let，好比 let string s ;

能够起到在循环中给闭包传递变量的做用，

Task 库

返回多个返回值，好比 D# 中

public (int i, string s) Foo()

{

int i;

string s;

…… // 对 i, s 操做

return (i, s);

}

var r = Foo();

r.i …… // r.i 表示返回的 i

r.s …… // r.s 表示返回的 s

编译为 InnerC 是这样：

struct R<>1

{

int i

string s,

}

Foo()

{

R<>1 r ;

r.i …… // 对 i 操做

r.s …… // 对 s 操做

……

return r ;

}

R<>1 r = Foo() ;

r.i …… // r.i 表示返回的 i

r.s …… // r.s 表示返回的 s

D# 是否要支持 async await 语法？

我曾经想过用闭包 + 观察者来取代 async + 职责链，但后来发现，闭包和职责链好像更配，这有点讽刺 ……

但其实闭包 + 观察者也是能够的，好比 Cef 中 ResourceHandler 的方法里能够 return true / false ; 和 callback.Continue() ;

若是当前就处理完了任务，则能够直接 return true / false，告知 Cef 能够进行下一个任务，

若是当前任务异步执行，则能够等异步任务完成时调用 callback.Continue() 告知 Cef 能够进行下一个任务。

今天看到群里有网友介绍 kooboo json 使用表达式树提升效率， https://github.com/Kooboo/Json/blob/master/Kooboo.Json/Formatter/Deserializer/Expression/CollectionBuild.cs

这样固然很好，可是我仍是以为表达式树太复杂了，我以为应该写 C# 代码来动态编译就能够。

好比

“ obj.name = dataRead [ \“ name \” ] ; ”

这是 ORM 里给 Entity 属性赋值的代码，这能够算是 C# 脚本。

这种作法只是第一次编译时可能比表达式树多一点时间，编译完成后运行效率是同样的。

其实第一次编译时也多不了多少时间，只是多了文本语法分析的时间。

之后 D# 也要这么干，提供动态编译，支持 D# 脚本。

D# 是不会提供 C# 那样的表达式树的。

C# 的表达式树就是面向对象泛滥的结果，认为何均可以用对象来表达，

其实字符串表达的会更好。

在 D# 看来， C# 的 Emit 和 Expression 是没有意义的堆砌。

在 D# 脚本看来， C# 的 Emit 和 Expression 是不须要的。