Talk:Haskell/The Curry–Howard isomorphism

Minor correction
I must respectfully disagree with the person who disagrees below! I found this chapter to the clearest introduction to the CH isomorphism I have come across on the web. I hope the author continues on beyond propositional logic and talks about encoding quantifiers. Anyway one minor correction: Where it says As we remarked in the first section, the implication P → Q is true if Q is true, regardless of the truth value of P. While true this statement didn't seem to have any bearing on what followed. I think what it ought to say is   As we remarked in the first section, the implication P → Q is true if P is false, regardless of the truth value of Q.


 * I'd say both ways make sense in this context. The statement currently in the text is pointing out that if Q is true then P → Q is always true, even if P is false -- and so if we have two arbitrary types  and   and   is inhabited then   is inhabited as well, even if   happens to be  . I do think you version matches more closely how 'ex falso quodlibet' is usually explained. However, since the current text indeed reflects the discussion in the first section, I will leave it as is for the moment, and have another look at it when, at some point in the future, I get to work on this chapter.


 * By the way, thanks for the feedback! Glad to see the book is being helpful. While there are a few things to improve in this chapter, when I get down to it I will be sure to keep an eye towards preserving what is working well.


 * Cheers, Duplode (discuss • contribs) 23:54, 19 February 2017 (UTC)

Curry-Howard
I'm running out of steam here. I'm not sure I know enough to write the last two sections, and this article lacks a sense of direction at the moment. I think it needs to be either more expansive, mentioning other structures like Functors and how they correspond, or perhaps more detailed, formalising the concept of the isomorphism and mentioning e.g. that the preservation theorem of a reasonable type system guarantees that a logic system is consistent (i.e. only theorems can be derived from theorems). Anyway, if anyone wants to take this one up, feel free. DavidHouse 21:48, 25 January 2007 (UTC)


 * This chapter is going pretty good and I also like the denotational semantics chapter. Please keep at it.  It may be possible to suck in some stuff from the Wikipedia article Combinator which explains stuff like the T-transformation.    The section is a lot more understandable than Curry-Howard and again maybe some cross-importing could help both articles.  I'm new to this stuff so I don't think I can contribute anything myself, but it's helping me learn.  64.160.39.153 05:04, 4 March 2007 (UTC)


 * I must respectfully disagree with the assessment that "This chapter is going pretty good". It's pretty much incomprehensible to anyone who is not already well-grounded in the subject. About the only sentence that is truly comprehensible for a newcomer is: "The Curry–Howard isomorphism, hereafter referred to as simply CH, tells us that in order to prove any mathematical theorem, all we have to do is construct a certain type which reflects the nature of that theorem, then find a value that has that type." But proving theorems is not what is of interest in programming. What is significant about CH is the opposite implication: that if the types of a program can't be used by CH to formulate a valid theorem, then the program is going to have problems generating appropriate values for its specified types. Compilers usually are constructed to report this as a major error and not produce such an erroneous program. "Certain type" should probably be plural, by the way. A compiler essentially must take the types of a program (both the explicit ones and those inferred) and use CH to convert them to valid theorems (if it can). It can also use unification to infer missing types from theorems provable by known types. My suggestion, since I myself am not an expert in CH, is for the author to refresh himself with a thorough study of CH and then revise the chapter. Delete the "crash course in formal logic" since that should be a chapter by itself. Instead, be more thorough in specifying how types get lifted to logical propositions. The Either type, for instance, is not a good equivalent to disjunction since in Haskell, Either is typically only used in error situations while disjunction is perfectly valid and evaluates to true when a is true or b is true and only is false if both are false. A better example is a union type where all constructors represent computable values exclusive of error conditions. The Void discussion is pretty much incomprehensible, especially since this Void type apparently doesn't mean the same thing as C or C++ void, where void is the "don't care" type, because values of that type are never examined (and therefore can exist or not at the whimsy of the programmer). Falsity in the CH isomorphism does not correspond to a "don't care" value, but rather to a program failure of some kind, technically _|_ (bottom), or in Haskell terms, to an error or an exception or a nontermination. Dlw20070716 (discuss • contribs) 12:53, 17 July 2015 (UTC)


 * The main issue, I guess, still is the one the original author pointed out eight years ago in the topmost comment: this chapter has useful information, but little structure or direction. It would be necessary to show what the point of CH is (i.e. essentially what you have said just above) and illustrate that with a handful of well-chosen examples.


 * Comments on some of the other points you raise:
 * "Delete the 'crash course in formal logic'" − that may well be the sensible thing to do. In fact, I'm not even sure if this book is an appropriate place for covering that subject at all. Here at Wikibooks we have e.g. Logic for Computer Scientists which, as far as a two-minute glance can tell, is pretty good (though very cold in approach). Edit: there is also Formal Logic, which seems to be more accessible.
 * "The Either type, for instance, is not a good equivalent to disjunction" − I would argue that is not the case. The -means-error thing is just a convention for certain use cases, and there are plenty of places where it isn't used. One example already covered by the book is the the   class, whose methods use   and   simply as tags to indicate values should be treated differently, with no extra meaning attached. If we assumed   was problematic, the only alternative would be introducing a   type isomorphic to it. I believe, however, that would be an unnecessary complication (and none of the other treatments of this topic in Haskell that I'm aware of do that).
 * The  discussion could be made clearer indeed. By the way, as of GHC 7.10  is in the standard libraries.


 * Finally, if you feel like contributing please don't be afraid to join just because you are "not an expert in CH"! I am no specialist either, but I'm sure we are capable of improving this chapter. As for me, I have a couple chapters in the first part of the Advanced Track to take care of first, but I will come back here ASAP. Thanks, and cheers, Duplode (discuss • contribs) 19:28, 17 July 2015 (UTC)


 * (P.S.: Is the comment about the "second" monad law in the Category Theory talk page yours? If so, I replied to it there.)

It would be nice to get rid of phrases like "Firstly, we know the two axioms to be theorems" - unfortunately, I am not a specialist in this area, and I don't know what the author means, but probably not this. Vlad Patryshev 02:29, 3 May 2007 (UTC)

While the very broad and very narrow issues have been tackled, as a new comer to this topic, I see no narrative connection to "isomorphism". Sure other forms of morphisms have been covered, but I am totally lost when it came to finding the meaning of the title. It's application and importance are perhaps hidden and in plain sight for an experienced logician, but I can't. I hope this important topic gets some serious attention. Forget about examples until isomorphism has been explained in more than one way.
 * On first approximation, "isomorphism" is a synonym for "equivalence".
 * More precisely, the term "isomorphism" refers to a mapping that shows the equivalence of two mathematical structures. In this case, the Curry-Howard-Isomorphism is the mapping that assigns a proposition to each type such that that the products of types is mapped to the logical "and", function types are mapped to the logical implication and disjoint sums are mapped to the logical "or".
 * apfe&lambda;mus 12:14, 30 December 2009 (UTC)

May apologies if this is not the right place, but I did not know where else to go: THANK YOU! THANK YOU! THANK YOU! This content is excellent. I have struggled to find a quick and clear reference to this topic and this book entry explains it cleanly and succinctly. And it doesn't require more than a simple understanding of related topics. Great job! Thank you.
 * On behalf of the original authors: you're welcome :-) Duplode (discuss • contribs) 01:32, 29 June 2015 (UTC)

Fixed point combinator
What about fix :: (a -> a) -> a Doesn’t the existance of this function mean that the type (a -> a) -> a is inhabited, which can be used to prove any theorem? I guess it has something to do with recursion, but it should be mentioned. --Nomeata 21:14, 16 July 2007 (UTC)


 * That's true,  represent an inconsistent theorem. But   is a primitive, every recursive function can be expressed in terms of it. Thus, you can remove it from the language.
 * In other words, the Curry-Howards-Isomorphism only applies to languages like the simply typed lambda calculus that don't have general recursion.
 * -- apfe&lambda;mus 12:06, 30 December 2009 (UTC)

Polymorphic types
I'm become confused early on in the article because it says there is no such thing as a function with type a -> b, yet this type is seen all the time for functions in Haskell. It says we can only talk about this in the context of some concrete types, but I don't really see how that's true with polymorphism. Given how common it is to see a -> b functions in Haskell, could someone edit the article to clarify why that isn't applicable here? Maybe in the system describing the isomorphism there is no such thing as polymorphic types?


 * It becomes clear when explicitly writing down the implicit universal quantifiers: a->b here means  i.e. with the standard mathematical notation $$\forall a,\!b.\ a \to b$$. A function of that type would be able to convert an arbitrary type a to any other type b you'd like to, essentially casting types which is impossible. In the Curry-Howard isomorphism, this type would correspond to a theorem "from all propositions a, we can deduce any proposition b" which is impossible, too.
 * One the other hand, every function like  is of course an instance of this type-scheme, i.e. there is a substitution   that unifies   and  . This means that we can use   as an argument to a function like
 * Note that  doesn't take an argument of type , that would give it some type like
 * In conclusion: there is no function of type  but many (all) functions are of the form   for some concrete a and b. Does that answer your question?
 * Arguably, it's the job of the chapter Haskell/Polymorphism to detail  and stuff. Hm, maybe one should name it "Polymorphism Basics" or "System F", maybe "Haskell type system explained". It's pretty much a prerequisite to the Curry-Howard isomorphism or Existential types. Ah, and the Curry Howard chapter needs polishing, too. Meanwhile, there's a tutorial  by Tim Newsham (but I'm not sure whether using the special   type constructor is a good idea).
 * -- apfe&lambda;mus 09:21, 13 November 2007 (UTC)
 * In conclusion: there is no function of type  but many (all) functions are of the form   for some concrete a and b. Does that answer your question?
 * Arguably, it's the job of the chapter Haskell/Polymorphism to detail  and stuff. Hm, maybe one should name it "Polymorphism Basics" or "System F", maybe "Haskell type system explained". It's pretty much a prerequisite to the Curry-Howard isomorphism or Existential types. Ah, and the Curry Howard chapter needs polishing, too. Meanwhile, there's a tutorial  by Tim Newsham (but I'm not sure whether using the special   type constructor is a good idea).
 * -- apfe&lambda;mus 09:21, 13 November 2007 (UTC)
 * -- apfe&lambda;mus 09:21, 13 November 2007 (UTC)