编程语言设计之路-3-部分函数式语法

函数式将会成为主流, 主要原因我就不说了, 网上多有介绍, 我这里说一下我个人认为网上没有提到的几点.

1, 函数式比命令式语言更加纯粹. 语法少很多

2, 不再为临时变量而纠结. 函数式中没有循环, 使用嵌套函数(闭包)+递归可以替代循环, 而且编译出来的代码, 应该差不多的. 好处呢看个简单的例子, 一个比较长的函数的话, 往往中间很多临时变量, 那些变量到后来有没用到, 在命令式语言里是不能直接看出来的, 而使用闭包, 就能清晰的将临时变量划到闭包中, 临时变量不再纠结. 更多时候还能避免全局变量的使用. 代码更加的清晰.

3, 函数式更便于思维, 仔细想一下, 递归的函数更容易想出来呢还是循环的版本?

 

说到这里, 我想起javascript了, 很纠结的语言, 由于闭包的实现方式是使用scopechain, 所以其函数式代码的性能降低了很多.

 

这两天有一点状态, 设计了一个语法解决了很多纠结的地方(示例代码中的其他语法并未定, 只是为了举例而随便选的一种)

看看这一个语法(注意其纯粹性, 是一个语法, 其实就是增加一个函数左侧实参的语法)

1,

someFunc(obj: SomeObj){}

o = new SomeObj

纠结的版本:

someFunc(o)

使用该语法的版本:

o->someFunc

2,

如要写程序打印1到100的和是多少

print 100 -> sum(n) {

  n == 1 ? 1 : n + sum(n - 1)

}

看看纠结的版本:

print(function sum(n){

  return n == 1 ? 1 : n + sum(n -1);

}(100));

这里忽然想说一下我的这个语言中常量表达式的定义, 常量表达式由其他常量表达式组成, 可以是字面量或者纯函数(没有副作用的函数), 所以可以看到我们这里的100 -> sum(n) 其实是一个常量表达式, 是可以在编译期决定值的. 而print函数是IO函数, 不是纯函数. 所以优化后的代码大概是5050 -> print

3,

额外的功能(其实就是carry, 如果要更灵活的carry就自己redefine吧)

redefine版本:

pow2(n){ pow(2, n) }

使用该语法的版本:

pow2 = 2 -> pow

 

为了纯粹性正在考虑是否放弃右侧实参.

 

 

模式匹配语法, 正在考虑是否用类似下面的

a == {

| 1 => "mon"

| 2 =>"tus"

| ""

}

考虑第一个竖杠是否可以省略

a instanceof {

| A => A.typi

| B => B.typi

| Object.typi

}

模式匹配理论上讲是顺序匹配的, 但是如果左侧的大部分是常量的话, 可以将那一部分优化成接近switch的哦.

a -> {

| cond_func1 => 1

| cond_func2 => 2

}

左侧表达式是可以用函数的

isItemInArray = item == {| array.each }

左侧表达式可以是迭代器, 右侧为空匹配时默认返回true, 都不匹配时无默认值则默认返回false

 

模式匹配语法让if elseif不再纠结. 减少了一些重复代码. 更重要的是代码看起来更清晰.