Djinn如何工作？
好的，所以我意识到我可能会对我的余生感到遗憾，但是… Djinn是如何工作的？
该文件说，它使用的algorithm是“LJ的延伸”，并指出关于LJT的长时间混淆的论文。 尽我所知，这是一个非常复杂的高度规则化的系统，用于确定哪些逻辑陈述是真实的还是错误的。 但是，这甚至不能解释如何将types签名转换为可执行expression式。 大概所有复杂的forms推理都是以某种方式参与的 ，但是画面是非常不完整的。
这有点像我试图在BASIC中编写一个Pascal解释器的时候。 （不要笑，我只有十二岁…）我花了好几个小时想弄明白，最后我不得不放弃。 我只是无法弄清楚，从一个包含整个程序的巨型string中得到的东西，到可以与已知程序片段进行比较的东西，以便决定实际执行的内容。
答案当然是你需要写一个叫“parsing器”的东西。 一旦你理解了这是什么以及它做了什么，突然一切都变得明显了 。 哦，编码它仍然不是微不足道的，但这个想法很简单。 你只需要写实际的代码。 如果我十二岁的时候我就知道parsing器，那么也许我不会花两个小时盯着一个空白的屏幕。
我怀疑Djinn在做什么从根本上是简单的，但我错过了一些重要的细节，解释了所有这些复杂的逻辑体操如何与Haskell源代码相关…
Djinn是一个定理certificate者。 看来你的问题是：定理certificate与编程有什么关系？
强types编程与逻辑关系非常密切。 特别是ML传统中的传统function语言与直觉主义命题逻辑密切相关。
口号是“程序是certificate，程序所certificate的是它的types”。
一般你可以想到
foo :: Foo 说foo是配方Foo一个certificate。 例如types
a -> b
对应于从a到b函数，所以如果你有a的certificate和a -> b的certificate，你有a -> b的certificate。 所以，函数完全对应于逻辑中的蕴涵。 同样
(a,b)
对应于连词（逻辑和）。 所以逻辑同义a -> b -> a & b对应于Haskelltypesa -> b -> (a,b)并且有certificate：
\ab -> (a,b)
这是“和引入规则”，而fst :: (a,b) -> a和snd :: (a,b) -> b对应于2“和消除规则”
类似地， a OR b对应于HaskelltypesEither ab 。
Haskell Curry和William Alvin Howard之后，这种对应有时被称为“咖喱霍华德同构”或“ 咖喱霍华德通信 ”
这个故事在Haskell中是非整体性的。
Djinn“只是”一个定理certificate者。
如果你有兴趣尝试编写一个克隆，那么这个“简单的定理certificate者”的谷歌结果的第一页就是这篇文章，它描述了一个看起来是用SML编写的LK的定理certificate。
编辑：关于“如何certificate定理是可能的？” 答案是，从某种意义上说，这并不难。 这只是一个search问题：
考虑这个重申的问题：我们有一套我们知道如何certificateS的命题和一个我们想要certificate的命题P.我们做什么？ 首先，我们问：我们已经有S的certificate了吗？ 如果是这样，我们可以使用它，如果不是的话，我们可以在P上模式匹配
case P of (a -> b) -> add a to S, and prove b (-> introduction) (a ^ b) -> prove a, then prove b (and introduction) (avb) -> try to prove a, if that doesn't work prove b (or introduction)
如果没有这些工作
for each conjunction `a ^ b` in S, add a and b to S (and elimination) for each disjunction `avb` in S, try proving `(a -> P) ^ (b -> P)` (or elimination) for each implication `a -> P` is S, try proving `a` (-> elimination)
真正的定理certificate者有一些智慧，但这个想法是一样的。 “决策程序”的研究领域是对某些保证工作的公式进行检验的策略。 另一方面，“策略”则考虑如何优化certificatesearch。
至于：“如何将证据翻译成哈斯克尔？”
正式系统中的每个推理规则都与一些简单的Haskell构造相对应，所以如果你有一个推理规则树，你可以构造一个相应的程序 – Haskell毕竟是一种certificate语言。
意义介绍：
\s -> ?
或者介绍
Left Right
并介绍
\ab -> (a,b)
并消除
fst snd
等等
奥古斯特在他的回答中说，他在迪金实施这个方法对于这个答案有点乏味。 我敢打赌，你可以想象如何实现它自己。
从最一般的angular度来说，根据库里 – 霍华德同构，types和命题之间是对应的，也是价值和certificate。 Djinn使用这个信件。
做更具体的说，你要find一个types为(a, b) -> (b, a)的Haskell项。 首先你把这个types翻译成逻辑语句（Djinn使用命题逻辑，即没有量词）。 逻辑陈述(A and B) is true implies (B and A) is true 。 下一步就是certificate这一点。 对于命题逻辑，总是可以机械地certificate或反驳一个陈述。 如果我们能够反驳它，那么这就意味着Haskell中没有相应的术语。 如果我们可以certificate这一点，那么就有一个Haskell这个types的术语，此外，Haskell术语与certificate的结构完全相同。
最后的声明必须是合格的。 你可以select不同的公理和推理规则来certificate陈述。 如果你select了一个build设性的逻辑，certificate和Haskell之间只有一个对应关系。 “正常”（即经典逻辑）具有像A or (not A)这样的公理。 这将对应于Haskelltypes或Either a (a -> Void) ，但没有这种types的Haskell术语，所以我们不能使用经典的逻辑。 任何命题陈述在build设性命题逻辑中都可以被certificate或者被certificate是错误的，但是比起古典逻辑来说，这样做更为重要。
因此，总而言之，Djinn将逻辑上的types转换为命题，然后用build构逻辑的决策程序来certificate命题（如果可能的话），最后将certificate转化为Haskell术语。
（说明这是怎么工作的太痛苦了，但是在白板上给我10分钟，这对你来说很清楚。）
作为最后的评论让你思考：如果你有Scheme的call/cc可以实现Either a (a -> Void) 。 select一个更具体的types，如Either a (a -> Int)并找出如何。
也许我看着这一切都是错误的。 也许所有这些forms逻辑的东西只是一个分心。 而不是盯着LJT或其他什么的演绎规则，也许我应该做的就是看Haskell。
Haskell中有6种可能的expression方式？ 每个人对它使用的variables都有不同的types约束，对吗？ 所以，也许我只是为函数types中的每个参数生成一个新的variables，并开始看到我可以构造的expression式。
甚至不需要在蛮力search中生成所有可能的expression式。 如果你的参数都没有函数types，那么尝试函数应用就没有意义了。 如果你的所有参数都是多态的typesvariables， caseexpression式不会帮助你。 等等。 可用的types告诉你哪些types的expression式可能工作。
如果您允许您的代码调用现有的顶级函数，事情会变得更有趣。 除了多态types的有趣的范围问题之外，还有一个问题是要弄清哪些函数可以帮助你。
很明显，我将不得不离开，想一想这一段时间…
