最近刚刚离了职，便休息一会做点自己想做的事，于是花点时间写了这个解析字符串为Lambda表达式并编译为委托的模块：LambdaParser。

　　介绍

　　先举个最简单的例子让大家明白LambdaParser模块究竟做什么：

Func<int, string> f = ExpressionParserManager.ParseDelegate<Func<int, string>>(
　　　 "m=>2+m.ToString("000")");
string result = f(2); // "2002"

　　简单的说，LambdaParser模块就是在运行时编译Lambda表达式。

　　原理

　　LambdaParser的最主要方法ParseDelegate接受一个代码字符串，返回一个委托。

　　LambdaParser会分析输入的代码字符串，然后一个一个构造Lambda Expression，最后编译成委托。

　　这样，我们就能动态编译并执行代码。

　　若是每次都这样，性能当然好不到哪里去，于是我在ExpressionParserManager做缓存，在下次调用时从缓存里取委托。

　　特点

　　在运行时编译Lambda表达式不是一个常规解决方案，但有时候很有用，它比反射更灵活，更快，更易懂。

　　一些说明

　　1.基于Lambda表达式，所以当然也不支持Lambda表达式不支持的，如：赋值操作等。

　　2.只支持Lambda表达式，不支持Lambda语句。也就是说不能写多条Lambda语句，所以if,for,while等肯定是不支持的。

　　3.理所当然，支持数字运算，支持字符串拼接。目前尚未做编译优化，比如：1+2这种常量运算本来是可以在编译的时候就计算出来，但现在是原原本本的编译出来，在运行时去计算。字符串的拼接也一样。

　　4.目前尚不支持checked运算。

　　5.由于我是看了老赵的《这下没理由嫌Eval的性能差了吧？》才有这想法的，对于那一段Expression代码(DynamicPropertyAccessor构造函数)，当时花了N+M次的来回阅读，才勉强弄明白意思，于是计划写这个，所以我用老赵的思路也实现了一个FastEval，由于我这个类库本来就是做解析的，所以对于FastEval的参数也就原生的支持表达式语句，而不仅仅是属性名，所以我认为我这个FastEval实现比原本的Eval更快，更灵活：）