haskell - J 风格的副词、 fork 等是否通过主流函数式语言的库进行了模拟？

Question

是否曾经通过主流函数式语言的库尝试过通过动词、副词、 fork 等方式模拟 J 风格的超浓缩默契编程？

如果是这样，结果有多成功？

如果没有，是否有技术问题使这成为不可能，还是不值得做？

我对像 fork 这样的结构特别感兴趣，这些结构似乎与函数式编程中的基本概念并不直接对应。

Answer 1

默示编程不是与 Haskell 中的组合逻辑或无意义的无点风格非常接近吗？例如，虽然我不知道 J 从我收集到的东西中，但“fork”翻译了三个函数 f , g , 和 h和一个论点 x变成一个表达式 g (f x) (h x) . “将多个函数应用于单个参数，然后将结果依次应用于彼此”的操作是对 Curry 的 Schönfinkel 的 的概括。小号 组合子和在 Haskell 中对应于 Applicative Reader monad 的实例。

一个 fork Haskell 中的组合器使得 fork f g h x匹配上面指定的结果将具有类型 (t -> a) -> (a -> b -> c) -> (t -> b) -> t -> c .将其解释为使用 Reader 仿函数 ((->) t)并将其重写为任意仿函数，类型变为 f a -> (a -> b -> c) -> f b -> f c .交换前两个参数给我们 (a -> b -> c) -> f a -> f b -> f c ，即 liftA2 的类型/liftM2 .

因此，对于计算平均值的常见示例，fork +/ % #可以直接翻译为flip liftA2 sum (/) (fromIntegral . length)或者，如果有人更喜欢中缀 Applicative组合器，如 (/) <$> sum <*> fromIntegral . length .

If not, is there a technical issue that makes this impossible, or is it just not worth doing?

至少在 Haskell 中，我认为主要问题是极其无点的风格被认为是混淆和不可读的，特别是在使用 Reader monad 拆分参数时。