Typeof.net

Moescript 的模式匹配

2012-05-16 23:57

自从 vczh 说 “没有模式匹配的语言不是好语言” 后，我就用 Moe 的单子做了个模式匹配，没有去修语法。当然不是「完全没有修」，原来单子范本（Monad Schemata）里的 yield 动作就给改成 bindYield 了。这下子 Moe 的单子就更适合做 DSL 了。

大多数有模式匹配的语言，其匹配过程其实有两部分：

判断某个表达式是否满足某个条件（匹配）
如果满足，把它分解（提取）

在 Scala 里，这个过程可以用提取器（Extractor）来描述：一个提取器有个 unapply 方法来“拆解”送进来的对象，如果满足某个条件，则返回 Some(part1, part2, ...)，否则返回 None。一个提取器的案例是：

object Email {
    def unapply(str: String): Option[(String, String)] = {
        val parts = str split "@"
        if (parts.length == 2) Some(parts(0), parts(1))
        else None
    }
}

在 Moe 里，出于性能考虑，我不打算用数组存贮被拆开的各个部分。考虑到模式匹配里，提取器后面往往跟着一个动作，所以我打算把提取器做成这样：

def Email = [formMatch: f]
where f(got, miss) = (x) =>
    if(not (x is String)) 
        miss x;
    else
        def parts = x.split "@"
        if(parts.length == 2) 
            got parts[0], parts[1]
        else 
            miss x

这样一来，Email(<匹配动作>, <未匹配动作>) 就可以得到一个函数，对于丢给它的对象，如果满足一些条件，就提取之并交付 <匹配动作>，否则就交付 <未匹配动作>。这样，就可以串联两个提取器实现模式匹配里的“先到先得”原则：

extractor1.formMatch(match1, extractor2.formMatch(match2, allMiss))

明确思路以后就可以利用 Moe 的单子来构造复杂提取器了。单子（Monad）有个外号叫“可编程的分号”，是对流程本身进行的抽象。处理单子就可以用各种方法处理流程本身，从而得到传统语言难以完成的神奇效果，比如让函数可以从指定的地方断成两截，并且可以在你需要的时候执行后半截，成为各种被异步 API 困扰人士的救星。相信各位看过 Moe 文档里的异步单子（async）和列表综合单子（table）的看官都已经知道单子有多么逆天了。

利用单子做 DSL 的原理是利用单子范本（schemata）在 Moe 提供的两种绑定点（! 和 <-）对应的方法（bindYield 和 bind）上对流程进行处理。单子原语里

f!(<args>) 的定义是 schemata.bindYield(f, null, <args>, <接下来的流程>)
o.m!(<args>) 的定义是 schemata.bindYield(o.m, o, <args>, <接下来的流程>)
x <- e 的定义是 schemata.bind(e, (x) => <接下来的流程>)

注意到 bindYield 的形式和 extractor.formMatch 相似，尤其是那个 <接下来的流程>，和上面例子里串联提取器时候的 <未匹配动作> 链几乎一模一样。这就提供了利用 bindYield 做复杂模式匹配的可能性。下面就是模式匹配单子（matcher）的实现：

// From: Moescript src/prelude/prelude.moe
// Pattern match functions
def Matcher(G) = 
    var fMatch = (x) => undefined;
    def schemata = object MONAD_SCHEMATA_M, =>
        def @bindYield(extractor, thisp, got, cont):
            cont()
            fMatch = extractor.formMatch.call thisp, got, fMatch
    
    G.build(schemata)()()
    return fMatch

def export('match') match(x, G) =
    if (not G) Matcher(x)
    else       Matcher(G) x

下面是 match 的一个用例：

// Generate matcher functions
var matcher = match =>
    Array ! (first, second, tail) =>
        trace [first, second]
    String ! (s) =>
        trace s
matcher x

// Direct match
match x, =>
    Array ! (first, second, tail) =>
        trace [first, second]
    String ! (s) =>
        trace s

可以看到，match 的最末参数，一个 DSL里，对提取器（Extractor）进行 ! 调用（bindYield 调用）来构造模式匹配器。如果展开这个 ！，那么结果将是：

schemata.bindYield Array, null, ((first, second, tail) => ...), =>
    schemata.bindYield String, null, ((s) => ...) =>
        undefined

Matcher 里的 schemata.bindYield 从后向前搭建匹配函数，慢慢把 fMatch 成型。按照 schemata.bindYield 的定义，上面一大团东西的实际上就是：

Array.formMatch ((first, second, tail) => ...), (
    String.formMatch ((s) => ...), (() => undefined))

这是一个函数，和 Email.formMatch(... , ...) 的结果一样，处理传入的对象，并处理相应的动作。这个 DSL 写起来很方便，只要在提取器和匹配后动作之间加入一个 ! 就行了。

Moescript 中的 Layout 过程

2012-05-14 15:29

Moescript 里在 lex 和 parse 之间有个过程，称为 Layout，来处理缩进。许多缩进语言的语法都不是上下文无关的，因此都必须有一个类似的过程来处理缩进。比如 Haskell 里就用一个函数来“修理”语素流，把缩进的代码块处理成 {...; ...; ...;} 的形式。具体过程可以看 Haskell 2010 Report 10.3 节。

在早期的实现里，Moe 的解析器会在语素化过程里同时处理缩进（生成 INDENT 和 OUTDENT 语素），然而近期的一个改进就是分离了 Layout 过程，使得解析器更简单效率更高，同时可以方便的把 Lexer “改装”成高亮器（现在我 Moescript 文档的高亮器就是直接用它的 Lexer 驱动的）。

Layout 过程分为两部分：第一步是去掉某些环境里的换行（比如括弧里的换行就会被忽略掉；运算符两边的亦然），另一步就是把换行（NEWLINE 语素）进行 Layout。

定义运算符 a ⊏ b 表示 a 是 b 的真前缀，即存在非空字符串 c，有 a + c = b。语素化过程中，每个换行语素（t）都记录了缩进数 j_t（一个字符串，包括空格和 Tab），那么 Layout 可以用函数 L(T, S) 表示，其中 S 为一个堆栈，维护已有的缩进序列。

一个缩进更深的行，表示你写了一个缩进代码块，故会产生一个 INDENT 语素，并且缩进堆栈会压入这一行的行首空白：

L([t : T'], [p : S']) = [INDENT : L(T', [j_t : p : S'])]
t 是 NEWLINE；p ⊏ j_t

然而进行比较必须堆栈非空。在堆栈空时，应该补充一个边界状况：

L([t : T'], [ ]) = [INDENT : L(T', [j_t])]
t 是 NEWLINE

缩进相同的两行，会把换行视作分号：

L([t : T'], [p : S']) = [SEMICOLON : L(T', [p : S'])]
t 是 NEWLINE；p = j_t

而对于缩出（j_t ⊏ p），情况就比较复杂了。对这种状况，栈顶元素 p 会弹栈，并产生一个 SEMICOLON 和 OUTDENT，之后继续处理这个换行语素，直到能归并到前面的状况为止。这时 L 的定义是：

L([t : T'], [p : S']) = [SEMICOLON : OUTDENT : L([t : T'], S')]
t 是 NEWLINE；j_t ⊏ p

如果 t 和栈顶元素 p 之间无法比较，就会报异常：

L([t : T'], [S]) = SYNTAXERROR
t 是 NEWLINE；其他状况

接下来就是完善 L 的其他情况

L([t : T'], S) = [t : L(T', S)]
t 不是 NEWLINE
L([ ], [p : T']) = [SEMICOLON : OUTDENT : L([ ], S)]
L([ ], [ ]) = [ ]

那么，在 Lex 之后，就可以用 L(T, [ ]) 来 Layout 语素，生成用于 Parse 的语素流。上面的 L(T, S) 模仿了 Haskell Report 里的一些形式。

JavaScript 常见误解，其一

2012-05-13 23:27

这里来澄清一些常见的 JavaScript 流言和误解，不论来自大神还是草根……

最长行匹配

这个骗到了无数学 JS 的人啊……JS 的规范里描述了在某些情况下为源码增加分号的行为，然而在某些人的书里，这个行为被描述成：

如果单行语素构成一个完整的句子，那么不管末尾是否有分号，都作为一个独立句子来执行。否则的话匹配多行，直到这些行共同构成完整句子或者出现分号为止。

很不幸，这是错的，而且正好和 ECMA Spec 相反。根据规范 7.9.1 节，自动分号插补的规则是：

When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:

The offending token is separated from the previous token by at least one LineTerminator.

The offending token is }.

When, as the program is parsed from left to right, the end of the input stream of tokens is encountered and the parser is unable to parse the input token stream as a single complete ECMAScript Program, then a semicolon is automatically inserted at the end of the input stream.

When, as the program is parsed from left to right, a token is encountered that is allowed by some production of the grammar, but the production is a restricted production and the token would be the first token for a terminal or nonterminal immediately following the annotation “[no LineTerminator here]” within the restricted production (and therefore such a token is called a restricted token), and the restricted token is separated from the previous token by at least one LineTerminator, then a semicolon is automatically inserted before the restricted token.

However, there is an additional overriding condition on the preceding rules: a semicolon is never inserted automatically if the semicolon would then be parsed as an empty statement or if that semicolon would become one of the two semicolons in the header of a for statement

这一段话相当冗长而且难以理解（因为牵涉到了编译原理里关于从左到右解析的相关知识），不过简单来说就是，如果解析器从左向右解析脚本时，如果看到前面的东西（语素），一个换行或者 }，比较“扎眼”的时候，就会尝试先在后面那个“扎眼”的语素前面插入一个分号，尝试分析。因而，在某些特殊情形（比如 return 后面）之外，其他的时候解析器都会优先把换行忽略掉，尝试继续解析到下一行。和所谓“最长行匹配”完全相反：最长行匹配会优先把换行当成分号而不是忽略之。或许最典型的例子就是

f
(g)

会被解释成 f(g) 而不是 f;(g)。

JavaScript 里所有数值都是浮点，因此位运算很慢

很不幸这又是一个“熟读规范”的人作出的错误预言。设想下，假如真的 JavaScript 里所有的数值都用浮点，那么第一个遭殃的肯定不是位运算，而是最简单的 for 循环：

for(var i = 0; i < a.length; i++)
    f(a[i])

在大多数的芯片上浮点运算比整数要慢的多（更何况 JavaScript 的数值是 double），没人会笨到用浮点数去做 for 循环的。事实上，绝大多数引擎都会“尽可能的”使用整数存储 JavaScript 数值，这个行为早在 IE6 出现的时候就有了。

位运算的性能事实上并不慢，这里有一个评测表明运算 ~~x 并不比 Math.floor(x) 慢。如果你要优化一些算数运算，使用位运算是一个有效的选择。

下面这个函数是我以前写的，用来混合两个 ARGB8888 颜色。

function blend(c1, c2){
    var a1 = c1 >> 24, a2 = c2 >> 24;
    var a = a1 + a2 - (a1 * a2 >> 8);
    var inv_a = 0x10000 / a | 0;
    var ma = a1 * (0x100 - a2) >> 8;

    var rb1 = c1 & 0xff00ff, rb2 = c2 & 0xff00ff;
    var rb = (rb1 * ma + rb2 * a2 >> 8) * inv_a >> 8 & 0xff00ff;

    var g1 = (c1 & 0xff00) >> 8, g2 = (c2 & 0xff00) >> 8;
    var g = (g1 * ma + g2 * a2 >> 8) * inv_a & 0xff00;
    return a << 24 | rb | g
}

Moescript 近况 + 编辑器计划

2012-05-13 20:10

最近主要还是在坑文档。Moe 的标准库，包括 std，stdenum 和 async 都合并到了一起，称为 moe/prelude（别吐槽名字），并且把「能做到的部分」全部 Moe 化。我把「二进制」moec 加上了一个选项，可以自定义 Runtime 以及其他全局变量的绑定，让写在 JavaScript 里的那些函数和用 Moe 写的函数能够协同工作。

这个网站是怎么做出来的？

2012-05-13 17:16

现在的 typeof.net 里面一个动态文件也没有，所有的东西都是用 eidoc 从 .ed 文件生成的 HTML。你也许会问我为什么不用 markdown 这种流行物，我要说，markdown 没有宏，没法作出 eido 这种逆天的效果。整个 typeof.net 我没有写一行 HTML，所有的东西都是 eidoc 生成的。

一个新开始

2012-05-13 17:16

把网站挪到 git 上面感觉还可以，我自己写了个 makefile 来生成全站的 html，而原始格式是 Eido。

总的来说效果还是可以的。虽然折腾 git 的钩子花了一段时间。

Some test

2012-05-11 16:14

Some test.

Some test

2012-05-11 16:14

Some test.