D# 语法

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

有关 ILBC / D# ，见《ILBC 白皮书》 https://www.cnblogs.com/KSongKing/p/11070978.html 。

D# 又名 Data ， D++ 。

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

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

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

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

比如， A 结构体，

struct A

{

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# 的一个核心特性模块基因。

有关协程，见《协程的实现方法》 https://www.cnblogs.com/KSongKing/p/11127010.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 是不需要的。

posted on 2019-04-14 11:46 凯特琳阅读(2467) 评论(0) 编辑收藏举报

刷新页面返回顶部

凯特琳

D# 语法

导航

公告