@bramblex 入乡随俗，变量名请统一使用希腊字母，

cata phi = In . fmap (cata phi) . out

其它的统一驼峰法咯（逃

哦，楼上我好像看错了，无视我对 Sql 的吐槽，我来研究一下 Model

然后楼主打算 type Sql = String 吗？你这是写 Python/NodeJS 呢……

@edsgerlin GHC 本来就有 LLVM 后端， GHCJS 也早就理论上可以用了，但是生成文件的体积惨不忍睹

Lib.Utils 是什么鬼东西啊，我虽然不用 PureScript 但是这些东西拿出来专门实现一遍也太鬼畜了吧？

还有为什么 .js 和 .purs 放在同一个目录下，不是有 pulp 吗？

楼主你是 C 写多了还是 C 写多了还是 C 写多了下划线是什么鬼？？？？？

@xi_lin 那个烂 app 啥都不发，所以我怀疑是苹果的……国内的卡我到现在都没绑定成功过，😂😂😂，没有发言权

纯好奇，我在美国用 Chase 是直接 iPhone + Apple Watch 通知的（包括余额），国内不会没这个吧？

@yishanhe Secure Enclave 是 5s 才有的， 5c 是 A6 。 现在有能力做到的是更新系统固件而不擦除数据，这点上我支持 @Halry ，确实很不安全，但估计 iOS 10 或者 iPhone 7 可以改变， maybe 5se 。

然后，有 Secure Enclave 之前，密码破解失败后增加时间是有软件负责的，可以去掉，有 SE 之后就不行了。但似乎数据抹除还是软件部分执行的，不知道为什么，没抹过，可能是 UI 不好看（逃。毕竟只要丢掉 SE 里的 key 就好了。

最后，有人指出现有的方法也不安全，因为可以用软件改机器时间，不过即使如此，如果 SE 尝试失败后的时间呈指数增长，应该可以溢出吧……搞一个 128bit 来记录时间，于是系统时间无论如何也就比这个小了。当然，也可能 SE 负责时间管理，或者用自己独立的计时器——它只需要查看时间流逝，不需要关心绝对时间。

本来还想说是主要还是网络问题，毕竟指导我妈半天虽然没搞起来但应该是 GFW 的错，后来想起来我在美国服务也不稳定……打脸

@weiceshi 在编程语言理论与编译技术方面，微软可以说是这几家大公司中最好的了，尤其是考虑微软剑桥研究院的灌水。这点上没必要黑也没法黑。

不就一个 type class ……能有多屌，看看 Haskell 加了 type class 后多出哪些东西就好了

@myid 要是楼主听你的就完了，每年都要给新的 GHC 重新适配一下，一不小心升级个 LTS 版本还会发现开发机内存不够 aeson 死活编译不过去。每年暑假都要把 ICFP 的 paper 读一遍，看到一个新思路手馋也得实现一下吧，永无安宁之日😂😂😂

我读错了，楼主是专门反 **Markdown** 的这种 ad hoc 的做法啊，不过就连 TeX 都加入了 $1+2$，楼主可能要失望了

@zxgngl 你这个自定义插件的思路倒是和 Haskell 的 Quasiquotation 差不多了。

总的来看我觉得挺有前途的，特别是那个 (@ @) 比较新颖，我之前自己写是让用户随便换 () [] <> {} 但是如果写自己的文档就会傻逼。但是若要替代 Markdown ，你需要加入两个支持，一个是最顶层的文本可以被直接当做段落处理，另一个是 Markdown 那个段内标记，**hello** 什么的。此外，你这个这么贴近 HTML ，你可能需要允许用户重新定义下 **hello** 的语义，所以 parse 完了之后可能还需要个 interpreter 。

可以把解释器分成两种，一种是基于语法树的解释器，一种是基于字节码的解释器。

举个例子， 3+4*5 ，基于语法树的解释器大概会是这样的：
data Expr = Lit Integer | Add Expr Expr | Mul Expr Expr

-- 构造语法树
ast :: Expr
ast = Add (Lit 3) (Mul (Lit 4) (Lit 5))

-- 解释器，使用模式匹配
eval :: Expr -> Int
eval (Lit x) = x
eval (Add e1 e2) = eval e1 + eval e2
eval (Mul e1 e2) = eval e1 * eval e2

而基于字节码的则会先把源代码翻译成一段字节码：
％ 0 = 3
%1 = 4
%2 = 5
%3 = mul i32 %1, %2
%4 = add i32 %0, %3

上述代码为 LLVM 中间表示，每个 %x 代表一个虚拟寄存器，有无数个虚拟寄存器。解释器会先把这段代码翻译成只使用一定数量的寄存器的形式，比如说：
%0 = 4
%1 = 5
%0 = mul i32 %0 %1
%1 = 3
%0 = add i32 %01 %1

这里只用了两个寄存器。接着，就可以解释执行这段代码。

另一种做法就是基于栈的解释器，大概长这样：
push 3
push 4
push 5
mul ;此时栈顶是 4 与 5
add ;此时栈顶是 3 与 20

据说这种方法实现起来比较简单，但是没有基于寄存器的解释方法来得快。如果没有记错的话， Lua 就是基于寄存器的解释，而 JVM 则很长一段时间都基于栈。

所谓的编译器，无非就是只完成了到字节码的翻译步骤，将执行交给硬件完成。不过编译器这个概念依然没有意义，因为硬件也是可以模拟的，比如说 Bochs ，比如说 QEMU 。难不成我们把 GCC 编译出来的代码换个环境之行，它就变成了解释器了？同理， JVM 也可以用硬件实现。我认为，只要记得基于语法树的解释和基于字节码的解释这一区别即可。

@liangguan5 大概是想重新模仿 Mac 家族 Late 2015 的叫法，但发现失败于是就放弃了

你这个还算幸福了，我贪大便宜放弃美区账户迁回国区 Apple Music ，之前我输入原来账户的密码还可以更新原来的 app ，现在已经不行了，非要电脑上同步一下，好伤心。

10.11.4 才是大动作， Safari 的 WebKit 也要更新了，有很多很棒的新特性。

尽管 Chrome 是政治正确。