摘要: 有的时候，IO的异常处理由于需要一个IOEnv类型的参数而显得非常麻烦。这个时候我们可以定制自己的一套异常处理系统，从而让程序变得清晰起来。自己的异常处理系统不同于IO，是没有副作用的函数集合。下面让我们看一看如何使用自定义的异常处理系统来分析一个四则运算表达式。  阅读全文      摘要: 说到底Kernel FP是一个脚本引擎，所以是需要API的。接下来的代码用来加载一些Kernel FP代码文件，并执行main函数。  阅读全文      摘要: 我们知道，循环本身是没有返回值的。所以在纯函数式语言下，跟IO有关的循环才有足够的副作用来产生价值。于是利用IO Monad，我们就可以实现循环了。循环是一个函数：  阅读全文      摘要: 前面说过，需要一个语法糖来组织IO，并且在其中的一步产生错误的时候立刻返回错误。现在我们看一段代码：  阅读全文     由于Kernel FP是纯的，所以一个函数的输出只跟输入有关系，所以从屏幕上输入文字的函数read是不能定义成func read::string的。因为根据这个性质，read的结果必须是一样的。所以一定要在每一次read的时候给不同的参数。但是其实没关系，这个可以用编译器来解决，就算read的顺序是运行时决定的。同样的问题也出现在Haskell的IO Monad上，由于资料无穷多，我就不详细解释了。下面给出没有语法糖的，能够正常并确定顺序地使用IO函数的一段代码：


    mainIO_0使用类型系统强制了IO函数的执行顺序，mainIO_1证明了IO也是可以使用正常的操作函数去进行复杂操作的。不过mainIO_0那种写法还是挺不舒服的，这就是语法糖发挥作用的啦。我只需要给出一种相对好看的语法，然后在语法分析的时候翻译成这样就行了。

    这种写法的好处是，万一其中有一个IO出了问题，错误信息会直接传达出去，中断函数执行。而且整个函数都是在类型系统的保护之下的。     考虑以下代码：

    这是三个函数，类型分别为：

    所以当我们写overloading的时候，究竟选择什么呢？三个类型都是可以接受的，而且都是可以完美通过类型推导的。于是我新加了一个规则。首先求出需要的具体类型（可能是含有参数的类型），然后计算从函数类型到具体类型所需要替换的类型参数的个数以及每个类型参数的解，最后计算出一个系数=数量×65536+解的深度和。

    深度的规定比较简单，基本类型深度为1，闭包类型为参数和结果两种类型的深度的最大值加1，带有参数的类型等于最大参数深度加1。所以在这个例子上，我们可以得到，T1到list char的解为T1=list char，list char到list char的解为0，list T1到list char的解为T1=char，系数分别是65538、0和65537，所以理所当然地挑选了第二个。下面看例子：

    下面是运行结果：
    现在的Kernel FP已经支持列表语法和操作符语法了。

    列表语法为[1,2,3,4,5]。原来是需要写成list 1 (list 2 (list 3 (list 4 (list 5 empty))))的。不过后面这种写法仍然是支持的。
    操作符可以自定义，凡是仅由“+-*/%<>=!&^|~@#$?”构成，而又不是“|”和“=”的记号都可以视为二元操作符。如果是+、-、*、/、%、<、<=、>、>=、==、!=、^、&&和||的话，优先级跟C++一样。如果是其他操作符，那么优先级一致而且最低。

    因为操作符也是个函数，因此将操作符作为函数使用的时候只需要加一对括号就可以了，不过中间不可以有空格。所以我们就可以定义“+”并写出下面的代码：

    下面是执行结果：

    操作符的优先级比函数低，因此sin a + sin b实际上是(sin a)+(sin b)。 于是下面的代码返回8.0：

    有了操作符之后，就可以慢慢为IO、Exception等复杂对象建模并且开发语法糖了。      摘要: 为了测试Kernel FP的健壮性以及进行一些bug的排除，一个四则运算式子的分析程序理所当然地就被实现了。代码如下：  阅读全文      摘要: 经过1个小时的奋斗，修了3个bug，终于使得Kernel FP能运行的代码渐渐多了起来。现在可以看看纯函数式语言简洁的代码及运行结果啦！

下面是很多用于测试的main函数：  阅读全文      摘要: Kernel FP已经可以运行小程序了。现在还处于测试阶段，过于复杂的程序估计是跑不过的。先简单介绍一下如何在C++调用Kernel FP的代码。  阅读全文