Talk:Lambda calculus

message: Does anyone know why Church chose lambda as the letter symbol?   Did it used to stand for something that started with L ?  — Preceding unsigned comment added by 87.114.213.103 (talk) 20:03, 4 September 2014 (UTC)
replies: text: It's not a letter, it was a typesetting problem. The first idea was to put a ^ on top of x, but the typesetters had a problem doing that. So they changed it to ∧x, which was later changed for convenience to λx. Source: History of λ-calculus and Combinatory Logic” by J. R. Hindley, F. Cardone (Handbook of the History of Logic, 5: 723–817, Elsevier, 2009). Blonkm (talk) 17:38, 7 September 2014 (UTC)
replies: text: If this is correct, then the lede is wrong. The name derives from the printers' use of the letter Λ (capital lambda) in the character pair ΛX meant to represent any character X with a circumflex glyph (aka hat, roof, house) over it, eg. x̂, ŷ, ẑ. (Numerous Diacritics are used in mathematics to indicate that the underlying variable has been changed in a specified manner, eg. õ, ō, ò, ó, ȯ, ö). I'd assume that the Church? paper's authors' choice of the circumflex was more or less arbitrary, but this would require their verification, the use of that notation may have prescedents.  The word "calculus" is often used to describe a system of computation or logic. I wonder why the caret wasn't used (^X) or was it?216.96.78.28 (talk) 23:13, 10 September 2015 (UTC)
replies: text:  And I really wonder what was the title of original Church's manuscript, that was sent to publishers? "What"-calculus was that then, where there was no lambdas in it?   — Preceding unsigned comment added by 212.75.255.51 (talk) 11:13, 24 September 2015 (UTC)
thread_title: Where did the name come from? Why the letter L?

message: just wanted to leave a note saying that the article seemed pretty confusing to read at first sight. (there seemed to be good links though and maybe i'll come back after understanding it to make it more readable.) Harshav
:Agreed. The introduction just seemed to ramble on (rather than the snappy thoughts that many good Wikipedia entries have). Usually this problem is limited to the mathematics pages of Wikipedia, not so much the computing ones (because a lot of geeks contribute and improve it).  Shall I slap an "unreadable, please resummarize me" icon on the top of the page? Whophd 08:32, 12 April 2007 (UTC)
replies: text: "+" is a binary function that returns the sum of two arguments, but "λ y. y + 2" specifies a function that takes a single argument and adds 2 to it. A B Carter (talk) 02:20, 8 June 2008 (UTC)
thread_title:  Note on readability 

message: The article mentions alpha-equivalence, but no direct explanation is given. That should probably be changed? Ran4 (talk) 20:39, 9 April 2010 (UTC)
thread_title:  Alpha-equivalence 

message: At the moment, the section "Arithmetic in lambda calculus" says "Note that 1 returns f itself, i.e. it is essentially the identity function, and 0 returns the identity function." If I understand the rest of the section correctly, this sentence has it the wrong way around: 0 is the identity function; 1 returns the identity function. So, I'm swapping the 1 and the 0. I'm definitely not an expert on this subject, though, so go ahead and revert my edit if I'm mistaken. —Saric (Talk) 20:44, 16 February 2008 (UTC)
replies: text: No, it was right before.  Think of this this way:  (3 f) is a function that applies f three times to its argument.   That is, ((3 f) x) is (f (f (f x))).  Similarly, (1 f) is a function that applies f once to its argument: ((1 f) x) is (f x).  So (1 f) is the same as f, and so 1 itself is nothing more than the identity function.  (0 f) applies f zero times to its argument, so ((0 f) x) is x.  So (0 f) is the identity function, and 0 itself is not the identity function, but the constant function that always returns the identity function.  Hope this helps.  -- Dominus (talk) 21:11, 16 February 2008 (UTC)

text: Oh, so it was already discussed here. ComputerScientist, read Dominus' answer to get the question you stated in your change comment anwsered. I agree with removing that confusing sentence altogether. Daniel5Ko (talk) 12:52, 18 May 2009 (UTC)
replies: text: Cheers. Sorry, wasn't thinking. But hold on: I think you need eta equivalence to get (1 f) = f. ComputScientist (talk) 13:17, 18 May 2009 (UTC)
replies: text:  I think so too. (And sorry for misspelling your user name) Daniel5Ko (talk) 13:27, 18 May 2009 (UTC)

text:  I disagree that it was confusing.  So far all three of you have correctly understood what  the article was trying to communicate, which is that 1 is the identity function, and 0 is the function that always returns the identity function.  The problem here is not that you misunderstood what the article was saying, but rather that you understood it correctly and didn't believe it.  So I am going to put back the offending sentence. —Dominus (talk) 18:14, 18 May 2009 (UTC)
replies: text: This was correct up until an anonymous editor screwed it up in the edit of 08:54, 1 December 2008.  —Dominus (talk) 18:20, 18 May 2009 (UTC)
replies: text:  Causing confusion and being correct are completely orthogonal. I still believe the sentence shouldn't be in its current context, but instead maybe moved somewhere else or removed. What's the value of it? Daniel5Ko (talk) 21:43, 18 May 2009 (UTC)

text:  I am not sure what the value is. We could instead say "(0 f) is the identity function, and (1 f) = f". But isn't this obvious from the definition and the previous sentences? [I was initially confused yesterday because I usually think of typed λ-calculi; 1 is not the parametric identity function in system F.] ComputScientist (talk) 06:33, 19 May 2009 (UTC)
replies: text:  Yes that is pretty obvious. And that's where the confusion comes in. The start of the sentence ("Note that...") as well as the actual content seem to imply great importance which just isn't there. In the search for the perceived deep meaning, the casual reader gets lost. (I'm still opting for removal) Daniel5Ko (talk) 21:49, 19 May 2009 (UTC)
replies: text: I am persuaded; let's get rid of it. —Dominus (talk) 13:20, 20 May 2009 (UTC)
thread_title:  Mix-up of 0 and 1 

message: 01-Nov-2008: I suggest adding a section "Controversy in lambda calculus" because it seems like overkill on fairly useless stuff. I still ponder "Why Johnny can't program" & "Why Johnny can't de-virus" & "Why Johnny can't word search" etc.  I think subjects like lambda calculus created a nerd-iverse (re: "universe") that wasted hours on useless math games.  Consequently, almost no one had time to focus on important topics, such as multi-word search.  Can you believe it's 2008, even Google had copied multi-word search 10 years ago (in 1998), and how many text editors today can search for a multi-word match?  As for "Why Johnny can't de-virus" as a 25-year ongoing nightmare, I think the answer lies in the fact that most people would buy a new "better" computer every time a virus killed their old PC: hence, some software companies had a vested interest in prolonging viruses that fostered sales of new software.  Even so, Johnny wasn't taught to track & stop viruses that would kill each PC owned by almost everyone he ever met. The Computer Virus Era was 1983-2009?, which seems to be ending with Windows Vista stopping viruses before execution. My view is to cite sources that consider lambda calculus to be a limited concept that thwarted the expansion of computer science in other areas.  For example, it has become common knowledge that languages are easier to program when using the standard syntax of algebra (but with words as variable names, not just x/y/z).  The vast majority of all software systems originally written in LISP have been re-written in procedural, non-list languages.  Simply as a matter of neutral balance, add some broader perspective to the article. -Wikid77 (talk) 02:22, 1 November 2008 (UTC)
replies: text: Hello. I'd like to see your references! I don't think you are criticizing the lambda calculus per se, but rather criticizing "people who spend time studying the lambda calculus". You could levy the same criticism on most advanced mathematical subjects: in part, the lambda calculus is studied for purely intellectual reasons. Another thing: you criticize lisp, but my understanding is that functional languages like Haskell are increasingly useful from a commercial perspective . 87.114.24.216 (talk) 09:43, 1 November 2008 (UTC)

text: So, the criticism is that people have (in fact) ignored developing certain applications because they're busy playing around with an unhelpful kind of formalism. This criticism seems to misconstrue lambda calculus as developed exclusively for use in computer programming languages with an eye to aiding the development of all useful applications. It is merely a tool, like any other. It also has applications in mathematical logic and linguistics, of which this critic seems to be completely unaware. 145.18.22.149 (talk) 11:11, 16 February 2009 (UTC)
thread_title: Proposed criticism of lambda calculus

message: I note that the link (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.9283) for Barendregt's book takes one to an internet shop.
I think that should not be so.
Could someone who is up to speed on it replace it with a proper reference with ISBN etc,
A link to the text online, if available would also be good.
PJTraill (talk) 14:40, 14 February 2009 (UTC)
replies: text: CiteSeerX is not an internet shop, but repository of free (when freely available) computer science papers. Don't get confused by the "metacart" stuff; you don't have to pay to get what's in it. See their about page. Pcap ping 07:40, 21 August 2009 (UTC)
thread_title:  Book link should not be to internet shop 

message: The fact the 1st section freely mixes lambda expressions with numbers is contributing to the confusion with typed lambda calculi, because neither that section nor the lead explain that those numbers are actually encoded as functions in untyped lambda calculus. Granted, there's a section on that, but that comes way later. WP:LEAD should be observed here, i.e. the lead should summarize the important fact that data types have to be encoded in untyped lambda calculus. Pcap ping 21:29, 5 August 2009 (UTC)
replies: text: As someone that yet know lambda calculus, the Informal description section itself seems to not be complete. Although the use of narrative is a helpful one, there seem to be some underlying assumptions made that makes it incomplete for someone unfamiliar with the subject matter. There is a chance it's just me, but I'm comfortable with functional programming, reduction, curried functions etc, but there still seems to be a couple of key concepts assumed from the reader (particularly in the subsections about Lambda terms and Alpha equivalence).  It might be useful if someone more could look over it and determine if it is missing something, or just my lack of comprehension. --59.167.232.215 (talk) 11:16, 5 July 2011 (UTC)
replies: text: Can you elaborate on the sentences you're having problems with? Those subsections seem to tiptoe around variable bindings and scope, but if you're fluent in FP and curring, this surely isn't what you're missing? Diego Moya (talk) 11:57, 5 July 2011 (UTC)
replies: text: As a lay reader, my problem with this section is that " lambda terms" is discussed but it is never actually defined. The term is simply used repeatedly in that section and the reader is left to infer what " lambda terms" are from context.  — Preceding unsigned comment added by 184.175.10.230 (talk) 13:42, 28 September 2011 (UTC)
thread_title:  Informal presentation issues 

message: See talk page of the fixed point combinator for details on why "recursive" is meaningless as used in that section; I've fixed the main article, and eventually I'll fix this too. Pcap ping 00:41, 22 August 2009 (UTC)
replies: text: I fixed some of it; needs more work. Potatoswatter (talk) 19:33, 10 March 2010 (UTC)
thread_title:  Rubbish in the fixed point section 

message: The article may need clarifying in general but the most important thing is fixing the meaningless example of  (λx.x+2) (where neither + nor 2 have been defined inside the theory).  It's disconcerting when the very example designed to clarify the subject isn't a valid part of the theory.  The writer should have used (λx.x x).
As for clarification, how about starting something like: "Lambda calculus, developed by Alonso Church in the 1930s is a technique for studying mathematic operations.  The basic idea is to encode mathematic concepts in a code, and allowing the code to be manipulated in certain rigid ways to mimic the operations.  Its importance nowadays is that it lent itself to computerization, inspiring the LISP programming language, and helped develop the general concept of programming functions."  At least that's my understanding of it.
CharlesTheBold (talk) 20:21, 1 October 2009 (UTC)
replies: text: Hi Charles. The example λx.x+2 is not meaningless. It makes perfect sense in a typed lambda calculus (and typed calculi are arguably most important in modern computer science). One could also add constants + and 2 to the untyped calculus, or understand them as shorthand for the constructions introduced later in the article. I have had a go at clarifying this, but please someone revert me if it is more confusing. I don't think (λx.x x) is a good first example because that is not a function that the beginner will have seen before (also, it doesn't make sense in most typed calculi). Perhaps the best thing to do is to make a general overview article, and to then have a special article on the untyped calculus. I haven't got time to do this, though. ComputScientist (talk) 07:10, 2 October 2009 (UTC)
thread_title:  Priorities on fixes 

message: I feel that all or most of the 2nd paragraph (starting "In the lambda calculus, functions are first-class entities...") should be cut.  Do others agree?  I can go line by line:
:In the lambda calculus, functions are first-class entities: they are passed as arguments, and returned as results.
This line is okay, but maybe it can be streamlined and merged into the previous paragraph.
:Thus lambda expressions are a reification of the concept of an unnamed procedure without side effects.
This line is bizarre.  I agree with what Charles Stewart wrote above on 18 March 2009.  I think it is also unnecessary and misleading to talk about side effects here.  The original untyped lambda calculus was "pure" in the sense that it was restricted to function abstraction and application, but it wasn't really about "purity" in the sense of deliberately avoiding state.  It wasn't because it couldn't be!  As Charles pointed out, the semantics of the lambda calculus is highly nondeterministic, not a realistic model of computation, and so to even talk about state-ful functions you have to make a departure from the "real" lambda calculus.  And in fact, all of the functional programming languages mentioned at the bottom of the paragraph (with the arguable exception of Haskell) do make this departure, and allow functions with side effects!
:The lambda calculus can be thought of as an idealized, minimalistic programming language.
This is good.
:It is capable of expressing any algorithm, and it is this fact that makes the model of functional programming an important one.
The second half is POV, and wrong in my opinion.  This fact is what allows for languages like Unlambda, but it is not what makes functional programming important.
:Functional programs are stateless and deal exclusively with functions that accept and return data (including other functions), but they produce no side effects in 'state' and thus make no alterations to incoming data.
What I wrote above -- this line is absolutely wrong for the standard definition of "functional programs", which includes programs witten in Lisp, ML, Scheme, etc.
:Modern functional languages, building on the lambda calculus, include Erlang, Haskell, Lisp, ML, and Scheme, as well as nascent languages like Clojure, F#, Nemerle, and Scala.
It does make sense to mention some of the functional languages inspired by lambda calculus.  But maybe that can be merged into the first paragraph.  And it is absolutely wrong to imply that these languages are stateless! Noamz (talk) 16:52, 25 October 2009 (UTC)
replies: text: Okay so I went ahead and cut the entire second paragraph, as well as the third because it seemed redundant.  I spent some time thinking about how to merge a bit of the 2nd paragraph into the 1st, but gave up when I realized the lede would only get more convoluted, and that the alternative lede that HowardBGolden proposed above is in any case much better. Is HowardBGolden still around? Whatever happened to that plan? Noamz (talk) 23:23, 30 October 2009 (UTC)
replies: text: I'm still around. I haven't proceeded due to some of the alternative ideas and also my lack of attention to this article. I would still like to work on this. Part of the discussion should be about the intended audience. If it includes readers who haven't had any previous exposure to LC, then I think a more discursive approach would help them get past the unusual notation (which was a stumbling block for me for a long time). I also think the article shouldn't become a textbook. Instead, the reader should be referred to a Wikibook or another text. — HowardBGolden (talk) 06:36, 10 November 2009 (UTC)
thread_title:  Cut 2nd paragraph? 

message: There appear to be inconsistencies in this section; it is stated that the following holds:
(λx.t)[x := r] = λr.t
And yet in an example,
((λx.y)x)[x := y] = ((λx.y)[x := y])(x[x := y]) = (λx.y)y
I'm not sure, but I believe that the assertion that (λx.t)[x := r] = λr.t is erroneous.  —Preceding unsigned comment added by 99.255.132.186 (talk) 22:00, 29 October 2009 (UTC)
replies: text: yes, that's a bug: should be (λx.t)[x := r] = λx.t Noamz (talk) 23:28, 30 October 2009 (UTC)

text: No. Alpha conversion is as you said; we associate the terms of form \lambda x . M with \lambda y . ( M [x:= y] ) provided that y does not occur in M. This is akin to being able to changed the variable in a "for" loop in C from i to j as long as you're not using j for something else; the name of a bound variable doesn't matter. In the capture-avoiding substitution section it's defining the actual substitution operation inductively on terms (what I wrote at M[x:=y] and what you wrote at M[x/y]). The "capture avoiding" part is this can only be done to free variables, so (\lambda x . M)[x:=N] = (\lambda x . M). I'm not quite sure in what context these two would be confused, so if you could elaborate any remaining concerns I'd be happy to try to address them and make appropriate changes. Thanks. Wgunther (talk) 02:53, 14 December 2010 (UTC)

text: This last statement is insightful and should be considered for the main article. Also, for understandability the free variables for the given functions (r,s,t) should be made explicit. [Cackowski] 
---
I believe the first part of
    if x ≠ y and y is not in the free variables of r
is superfluous since the fact that x is different from y is stated where they are "declared". --Andreas Lundblad (talk) 11:18, 9 June 2011 (UTC)

text: Sorry I don't know what you mean. The whole condition is necessary. Otherwise (λx.x)[x:=t]  becomes λx.t, which is wrong. ComputScientist (talk) 14:31, 9 June 2011 (UTC)
replies: text: But the whole section starts with Suppose t, s and r are lambda terms and x and y are variables where x does not equal y --Andreas Lundblad (talk) 12:48, 10 June 2011 (UTC)
replies: text: Thanks, I didn't notice that. I've fixed it now by removing that part at the beginning of the paragraph, which seems more reasonable than the particular clause. Feel free to undo me if you disagree. The same definition appears twice in the article, which is clumsy. ComputScientist (talk) 14:46, 10 June 2011 (UTC)
thread_title:  Capture Avoiding Substitutions 

message: I find the end of the paragraph on eta-conversion lacks some explanation. It states that
This conversion is not always appropriate when lambda expressions are interpreted as programs. Evaluation of λx.f x can terminate even when evaluation of f does not.
Could we have an example where the conversion is not appropriate, and an example where the evaluation of f does not terminate but the evaluation of λx.f x does ? Or are such examples too complicated ? 82.67.7.229 (talk) 15:33, 8 November 2009 (UTC)
replies: text: I think what this is getting at is that in many (in fact most) interesting evaluation strategies for functional languages, evaluation never occurs "under a λ", i.e., λx.f x is a value, even though f may express some non-terminating computation (computing a function).  Examples of languages with no evaluation under a λ are LISP and ML.  (Likewise Haskell, but there the evaluation of plain f is also delayed until it is needed (i.e., applied to an argument), so there is no difference in termination behavior.)  But so this is a bit odd way of putting it, because in these languages evaluation of λx.f x will always terminate. Maybe the subjunctive "can" was meant to quantify over different evaluation strategies? In any case, I think it would make more sense to talk about restrictions on βη conversion in the section on different reduction strategies. Noamz (talk) 00:43, 11 November 2009 (UTC)
thread_title:  Expand the Eta-conversion paragraph  

message: What is a capture? A fundamental notion in formal languages? Why then does it not have its own WP article? (Or why is it not linked?)--217.232.244.191 (talk) 14:30, 25 February 2010 (UTC)
thread_title:  What is a capture? 

message: I've tried reading this article several times and I have to say, I still don't have a clue what lambda calculus actually is. The opening sentence says that it's "a formal system for function definition, function application and recursion" (and only recursion has a useful wiki link). The article assumes that you already know what a whole bunch of things are and from that, you already know why you'd use lambda calculus. I think that the article would greatly benefit if it included the following things in the lead:
* A better definition of lambda calculus that would make sense to people with little to no knowledge of computer science. 
* As part of that definition, any technical words (i.e. something that someone with little to no knowledge in computer science would not be familiar with) that cannot be explained in a simpler way are wikified.
* A clear summary of why someone would use lambda calculus.
* A clear summary of the advantages of lambda calculus.
* A quick and clear delineation between typed and untyped calculus, explained in a way that it would make sense to someone with little to no knowledge in computer science. This can be further explained in a section of the article.
* A more concise history for the lead, perhaps just saying the date of its invention. Right now, the lead has three different dates and it's very confusing. A more in-depth history would be better suited in a section of the article.
I feel that with these changes, the article would become much more accessible to those who are not at all familiar with it. -Thunderforge (talk) 17:35, 13 May 2010 (UTC)
replies: text: The informal description section is a little better than the led, but I still get lost after it starts talking about anonymous functions (and I have no idea what the point of making a function anonymous is because that article isn't all that user-friendly either). At any rate, I was mostly talking about the lead, which is incredibly difficult to understand for someone without any knowledge of it. That's what most people read when they just want a cursory knowledge of what lambda calculus is and it's just way too confusing at this point. -Thunderforge (talk) 21:57, 13 May 2010 (UTC)
replies: text:  Strongly agree. No, the informal description does not cover it. There is nothing comprehensible in this article that actually explains in a non-technical manner what the lambda-calculus is. I have been visiting it for years in the hope that someone would provide a comprehensible introduction, but it has not improved. I cannot; I am one such non-specialist reader. Even quite technical articles such as the Goldbach conjecture manage this in comprehensible form. I myself wrote a non-specialist intro for Romansh language that provided this, which is still in place years later. This really needs fixing; without it, the articles on Lisp, John McCarthy & various others are incomplete. Liam Proven (talk) 13:49, 19 December 2010 (UTC)
replies: text:  I agree that the article, as is, is generally poorly written, organized, and typeset (in my opinion, both to specialists and non-specialists alike). It's been on my radar for awhile on things I'm going to try to fix up. If anyone wishes to help me with this (or, allow me to help them!) contact me through my talk page. I'll try to get started rolling out some adjustments over the next few weeks, starting with with the non-specialist summary and history sections (arguably the two most poorly written and the two most important sections for an encyclopedia article). Thanks Liam for reminding us. Wgunther (talk) 17:37, 19 December 2010 (UTC)
replies: text:  Happy to help if I am able! Not sure I'm competent, though. I won't be online much from 22-29 Dec '10 due to being on dial-up, though. Liam Proven (talk) 12:35, 20 December 2010 (UTC)

text: I am in the process of rewriting. The article is not friendly for anyone right now. My userpage has the beginnings of my attempt (which was the rewritten lead). As for your comment regarding the lead, set theory attempts to formalize mathematics with the notion of sets. So in set theory, there is a notion of a function, which is coded in the language of set theory. Lambda Calculus, historically, was an attempt to formalize mathematics with the notion of a function. One would then code math (eg. sets) into that language. Its like, you can code PA in ZFC, but it doesnt mean every natural number is a set. I mean, in PA you can code all of HF (hereditarily finite sets, which is V_\omega, or ZF-infinity) and nobody pretends all such sets are natural numbers. Its just a useful code. Category theory has been much more successful as an alternative to set theory, as far as foundations go. Lambda calculus in foundations was stifiled by the Kleene Rosser paradox early on, and HOL and Q_0 were systems that never really caught on. Wgunther (talk) 23:10, 17 February 2012 (UTC)
thread_title:  What exactly ''is'' lambda calculus? I still don't know. 

message: This page is missing a "History" section. --a3_nm (talk) 20:38, 16 October 2010 (UTC)
thread_title:  History 

message: I'm trying to merge the article AlphaRenaming into this (see its talk page), but I'm not quite sure of the difference (if any) between "alpha conversion" and "alpha renaming". Is there a difference? It seems as though alpha-conversion means "any legal renaming" (as defined formally in this article), while alpha-renaming means "renaming from a term with overlapping scopes to a new term with no overlapping scopes".
For example, \lambda x. \lambda x. x \Rarr \lambda x. \lambda y. y is a valid alpha-renaming (and alpha-conversion), whereas \lambda x. \lambda x. x \Rarr \lambda y. \lambda y. y is an alpha-conversion but not an alpha-renaming since it didn't fix the overlapping scopes, and \lambda x. x \Rarr \lambda y. y is also not alpha-renaming since the scopes weren't overlapping to begin with.
Or the two terms could mean exactly the same thing. I can only find colloquial uses of the term "alpha-rename", meaning "to make non-overlapping scopes", but not a true definition. It could be that the two terms are interchangeable. Anybody got a source? — MattGiuca (talk) 06:31, 28 October 2010 (UTC)
replies: text: Hi Matt. I think that "alpha renaming" is indeed sometimes a synonym for "alpha conversion". But perhaps compiler writers use it to mean what AlphaRenaming says. There are no references on the page AlphaRenaming. We should probably find some good references before merging it. (Sorry, I don't have any compiler books with me now.) ComputScientist (talk) 07:07, 28 October 2010 (UTC)

text: I just checked the purple dragon book; it doesn't mention Lambda calculus or alpha renaming at all (it only barely touches on scope). I have asked around a bit; I'm starting to think the two are interchangeable (which the names suggest anyway). — MattGiuca (talk) 23:30, 28 October 2010 (UTC)

text: I don't have access to it, but an academic gave me this quote from Turbak and Gifford, Design concepts in programming languages: "Consistently renaming the variables of an expression in a way that preserves its alpha-equivalence class is called alpha-renaming." So I'm going to assume the two terms are equivalent since I am yet to see anybody formally or informally define alpha-renaming as "an α-conversion that makes name resolution trivial by making sure that no name masks a name in a containing scope" outside of the Wikipedia article AlphaRenaming. — MattGiuca (talk) 00:38, 29 October 2010 (UTC)
thread_title:  Alpha-conversion versus alpha-renaming 

message: The function definitions used for encoding booleans and numbers uses a syntax that is not defined. It shows a function containing 2 or more arguments, which is never explained. This should either be introduced prior to this section, or not used. 
For example
: TRUE := λx.λy.x
Instead of what is written:
: TRUE := λxy.x  
—Preceding unsigned comment added by 198.36.95.12 (talk) 19:23, 13 April 2011 (UTC)
replies: text: It's explained in the "Notation" subsection of the "Formal Definition" section. Wgunther (talk) 20:20, 13 April 2011 (UTC)
thread_title:  Syntax of Lambda Calculus 

message: Hello. I refined the lead a bit boldly because I didn't agree with some statements recently introduced.
* First, I don't really believe the statement that the lambda calculus is "a formal system for studying ... variable binding and substitution". Primarily, variable binding and substitution are important because they are used in the study of the lambda calculus, rather than the other way round. (Perhaps the editor is keen on HOAS but that's a bit niche for this undergrad level article.)
* Second, it is wrong to say that "The portion of the lambda calculus relevant to computation is now called the untyped lambda calculus". A typed lambda calculus can be just as relevant to computation, particularly if it has recursive types. Many people believe that the right way to understand that untyped lambda calculus is as a "unityped" calculus with the recursive type U=(U->U).
ComputScientist (talk) 15:14, 4 January 2012 (UTC)
replies: text: Hi, I'm the author of the changes introducing the wording about binding and substitution. I disagree with your assessment of the lack of centrality of these concepts in the lambda calculus. I am a computer scientist working in the area of type theory and metatheory of formal languages. I am familiar with higher-order abstract syntax, but that has really nothing to do with why I introduced that phrasing. The lambda calculus, in comparison to alternatives such as combinatory logic, is all about variables and substitution. It is arguably the most central concept of the language, codified in the rules, and the method by which computation performs. Perhaps one could argue that the wording should have been changed to "a formal system for expressing computation by way of variable binding and substitution", or some other alternative, on the grounds that variables are not first-class objects in the same way they are in some forms of logical frameworks. However, I think that is a bit of a subtle distinction and one that non-experts should not be too concerned with. In any case, the concepts of binding and substitution deserve to be featured prominently in the lead because it is impossible to understand the lambda calculus without them. I agree with your second comment. 69.92.252.58 (talk) 06:07, 20 January 2012 (UTC)

text: So, as for your first comment, I disagree with you. Imagine you no nothing about the lambda calculus and you read the current first sentence; it has very little encyclopedic value. Binding and substitution are important because that is a way to formalize the theory of functions, which was the driving force for the invention of the lambda calculus. That should be in the first sentence. As for your second statement, I also disagree with you. The untyped lambda calculus historically is one of the major models of computation. No one should be talking about recursive types in the introduction of this article. The information that you state could be somewhere in the article, but putting it in the introduction hinders people without any background in the area. I will try to correct the lead sometime soon.    Wgunther (talk) 18:30, 22 January 2012 (UTC)

text: Hi. I think that it is possible to be precise while still giving an informal idea. On the first point, I now understand what 69.92.252.58 was getting at and I prefer the alternative wording that he suggests: "a formal system for expressing computation by way of variable binding and substitution". That's very nice. On the second point, I agree that recursive types don't need to be mentioned in the first sentence, but to say "The portion of the lambda calculus relevant to computation is now called the untyped lambda calculus" is to exclude typed calculi as irrelevant to computation, which is very wrong and misleading. It is correct, however, to say that the untyped calculus has played a central role in computability theory. ComputScientist (talk) 13:40, 23 January 2012 (UTC)
thread_title:  Refined lead 

message: The definitions of the Church numerals 0..3
are exactly the same between the common and
"alterate" notations.  They not only appear
the same; their source (mark-up) is the same.
Macareus (talk) 18:54, 15 March 2012 (UTC)
thread_title:  Section 6.1 Arithmetic -- alternate notation is no different 

message: The following is not a Y combinator, but seems to be able to function as one where one is needed: λx.(x x) 12.198.223.226 (talk) 21:46, 29 June 2012 (UTC)
thread_title:  Y Combinator and workalike 

message: Lambda calculus is of interest to non-mathematicians, particularly to software engineers.  In my experience, many intelligent software engineers complain that the topic is hard to learn not because of inherent complexity, but because most presentations of it are in a language that is trivial for mathematicians to understand but hard for engineers.
I attempted to expand a few terse paragraphs and had a 2.5k edit reverted nearly immediately by User:Ruud Koot with the comment undo: "sloppy writing rarely increases readability" (revision 528491773).  I do not defend the edits as perfect, but they were significantly easier for a non-mathematician to understand than before.
I have reverted the undo.  I am happy to work to come up with wording that preserves the readability of my version and yet corrects any flaws.  TJIC (talk) 12:24, 18 December 2012 (UTC)
replies: text: There are several issues with the next text. The main one is tone, which is too conversational for an encyclopedia article. For example, words like "we", "you", and "note", and contractions, should be avoided; bold to emphasize stress in sentences should be avoided; sentences that emphasize "software engineers" are out of place; and sentences such as "The formal definition of the syntax of lambda terms is simple." and "Variables need no further explanation." are chatty. I will go through and copyedit the text to make the tone more encyclopedic. — Carl (CBM · talk) 12:55, 18 December 2012 (UTC)

text: A lot of those edits were sloppy. I was going to revert until I saw someone else did. Two examples. First, you erased a paragraph with quite a lot of content in it, and replaced it with a sentence that begins "for software engineers..." and has very little content in it. Secondly, "The syntax of the lambda calculus means that some expressions are valid lambda calculus statements and some are not..." This sentence is nonsensical, and carries no content. Of course some things are terms and some things aren't. This is like adding to the PA article before the axioms of arithmetic the sentence "the axioms of PA mean that some things are natural numbers and some things aren't." I'll be the first to admit, this article is poorly written for non-mathematicians. A goal of mine has been a rewrite, especially the "informal introduction" section. But making it accessible to software engineers (which I'd even claim your edits do not to) does not make it more encyclopedic. Wgunther (talk) 13:08, 18 December 2012 (UTC)

text: Yes, the "Informal description" and "Formal definition" sections are quite messed up. For example, I don't see a need to go into detail about free variables or capture-avoiding substitutions in the first. It also seems odd that "Substitution" is covered under α-renaming instead of β-reduction. Finally, the section about "Encoding datatypes" should be significantly cut down in size. It duplicates a lot of content from Church encoding and takes up to much space in comparison to its importance. —Ruud 19:01, 18 December 2012 (UTC)
thread_title:  accessibility for non-mathematicians 

message: : I've by now lost any hope that this rewrite is going anywhere, so I've restored the previous incarnation of the article (which is also a very poor one, but alas...) I'm not going to point out any specific issues I have the rewrite: it's simply uniformly poorly written, incomprehensible, or worse.
: I don't think the stream of consciousness posted on the talk page is particularity helpful either. —Ruud 18:02, 18 July 2013 (UTC)
thread_title:  Recent "rewrite" of the article 

message: I plan to update this page with 
* User:Thepigdog/Lambda_Calculus
The changes are primarily editorial in nature, to improve the tone and readability of the article. To this end quite a bit of material has been moved. The goal is to simplify the lambda calculus page and redirect people out to other pages for technical details.
* Informal description - gone, replaced with new material (simple description and example of lambda calculus reductions and conversion).
* Formal definition - Moved to Lambda calculus definition
* Encoding datatypes - Replaced duplicated material with results.
* Recursion and fixed points - Gone (duplicated material from Fixed-point combinator).
* Reduction strategies - Moved to Lambda calculus definition
If all goes smoothly after the change I will fix up links to the page.
Thepigdog (talk) 04:27, 13 November 2014 (UTC)
replies: text: As previously, please don't. —Ruud 09:35, 13 November 2014 (UTC)
replies: text:  OK. But the current article seems arrogant, pretentious and badly written. You fix it. Thepigdog (talk) 10:29, 13 November 2014 (UTC)
thread_title:  Planned change 

message: In the section "Functions that operate on functions" an \rightarrow is used to write the identity. I would prefer to have "x \mapsto x", but then again I'm no computer scientist and so can't be sure this is not some sort of standard notation. Could someone who knows this stuff correct it or tell me why I'm wrong?
EdvinW (talk) 12:49, 11 December 2015 (UTC)
thread_title:  \rightarrow vs. \mapsto 

message: It should be made clear in the header what untyped lambda calculus is. I don't know enough about the subject to add anything of much use, sorry.
137.124.161.82 (talk) 21:19, 16 February 2016 (UTC)
thread_title:  [[Untyped lambda calculus]] redirects to this page. 

message: only a proposal, if I understand what is "alpha equivalence" and "beta reduction". how would it be, if it were:
:we soon talk about (1) α-equation and (2) β-reduction
:(1) about α-equation we talk so and so.
:(2) for  β-reduction we need to know, what is (a) free variables and (b) capture-avoiding substitutions
::(2.a) about free variables we talk so and so.
::(2.b) and about capture-avoiding substitutions  we talk so and so.
:so we can now talk about β-reduction.
thx for attention 94.219.96.38 (talk) 22:50, 3 March 2016 (UTC)
thread_title:  maybe you can put α equation and β reduction in the structure of the text 

message: The article states right in the beginning that the equivalence of lambda-calculus and Turing machines is the Church-Turing thesis. This affirmation seems to be wrong, though: The CT thesis states that these systems of computation, which had been PROVEN to be equivalent (and thus this equivalence is a theorem and not a thesis), describe, somehow, the human powers of computation. Equivalence in this sense cannot be proven mathematically, that's why it is a thesis.
See Wikipedia's own article on the topic as a reference: https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis
85.138.163.71 (talk) 23:07, 30 May 2016 (UTC)
replies: text: I agree, I've just removed the reference to the thesis, keeping the source as it refers to the actual theorem. I think this section is quite poor overall, so it might be worth rewriting it. − Pintoch (talk)  —Preceding undated comment added 06:43, 31 May 2016 (UTC)
thread_title:  Reference to Church-Turing thesis 

message: Hello fellow Wikipedians,
I have just modified  on Lambda calculus. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20040823174002/https://www.elsevier.com/wps/find/bookdescription.cws_home/501727/description to http://www.elsevier.com/wps/find/bookdescription.cws_home/501727/description
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 20:49, 12 September 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified one external link on Lambda calculus. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20011206080336/http://www.jetcafe.org/~jim/lambda.html to http://www.jetcafe.org/~jim/lambda.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 02:29, 11 May 2017 (UTC)
thread_title:  External links modified 

message: If x and y are variables then xy seems to have no direct mathematical meaning. Shouldn't this be discussed?  — Preceding unsigned comment added by G. Blaine (talk • contribs) 21:50, 29 June 2017 (UTC)
replies: text: In this context it means that x is a function of some sort and that you should apply it to y. The syntax is clearly discussed at the start of the article and this is just the same syntax. —David Eppstein (talk) 22:20, 29 June 2017 (UTC)
thread_title:  application xy 

message: The "informal description of lambda calculus" section currently goes into the technicalities of making substitution capture-avoiding, giving the same five definition cases as are later repeated in the formal definition section. I would suggest dropping those technicalities from the informal description—replacing them with just an example of how non-capture-avoiding substitution can go wrong—since these details are by far the most technical and confusing in the definition of the lambda calculus. (There are more confusing stuff you can do with lambda calculus, but the rest of the definition is pretty straightforward.) In view of past discussions, as recorded above on this talk page, I am however reluctant to do that change on just my own volition. 78.73.97.76 (talk) 22:22, 8 July 2017 (UTC)
replies: text: I would even suggest removing the entire "Informal description" section as it has multiple issues, in particular non-traditional notation for terms, use of the same symbol for meta-lambda-abstraction as for lambda-abstraction, and mostly duplicating the same content covered more formally; these issues create confusion. I think it would make more sense to have this article to start with formal definitions right after general description by removing duplicate content there and merging "Explanation and applications" and "History" into it. Codedot (talk) 07:29, 9 July 2017 (UTC)
thread_title:  Suggestion: Skip "capture-avoiding" in the informal description 

message: In section 3.2.2 "Functions that operate on functions", the examples given are not of functions that operate on functions. Some better examples are needed.
LoMaPh (talk) 19:14, 9 November 2017 (UTC)
thread_title:  Examples for "Functions that operate on functions" 

message: The use of the term "invention" suggest that the system is not a discovery, as would be held by mathematical Platonists. It also seems a like a pointless choice, given that anyone looking in that category would almost certainly not be looking for a model of computation.
:I'm inclined to agree with you. Removed category for now Poltair (talk) 12:49, 24 February 2019 (UTC)
thread_title:  Putting this in the category "American Inventions" suggests a view on Platonism 

message: After the example (λx.λy.(λz.(λx.z x) (λy.z y)) (x y)) the article states "Parentheses can be dropped if the expression is unambiguous". I would argue that the expression (λx.z x), which is a sub-expression of the above example is unambiguous. According to the three syntax constructions the expression (λx.z x) can be constructed as ((λx.z) x) or (λx.(z x)). So I believe there is missing information about precedence of the syntax constructions. Does the "." (dot) operator (syntax construction 2) have higher or lower precedence than the " " (space) operator (syntax construction 3)? --Jarl (talk) 08:22, 9 March 2019 (UTC)
replies: text: Formal definition -- Notation states, "The body of an abstraction extends as far right as possible: λx.M N means λx.(M N) and not (λx.M) N." WillNess (talk) 09:36, 21 May 2023 (UTC)
thread_title:  Unambiguous expressions and operator precedence 

message: This section explains that the equivalence of two expressions in the lambda calculus is undecidable, though it doesn't cite any references. Which references should be cited here? Jarble (talk) 16:15, 3 June 2019 (UTC)
replies: text: I added a reference to the original proof by Church (1936). Noamz (talk) 10:58, 6 June 2019 (UTC)
thread_title:  Undecidability of equivalence 

message: Hello,
how can operators or constants be brought in by application of these three rules? Are these supposed to be covered by the first rule? If so, the word "variable" is misleading to me.Stefan84556 (talk) 01:00, 27 July 2020 (UTC)
replies: text: I understand that this comment is old, but if you're referring to the introduction section, then I think it means that for certain applications (e.g. to analyse a particular programming language or to analyse a particular logical proof), one may extend the rules and syntax to include additional constants and operators. It doesn't mean that the syntax and rules stated allows one to create arbitrary constants and operators. AhoChan (talk) 10:31, 23 November 2020 (UTC)
thread_title:  Inductive definition of lambda terms unclear  

message: For example, \lambda x.((\lambda x.x)x) and (\lambda x.(\lambda x.x)) x denote different terms (although they coincidentally reduce to the same value).
There are too many different uses of x for these expressions to be reasonably understood. It's used as the argument for the outer and inner lambdas and, in the second expression, a useless free variable. Something like \lambda x.((\lambda y.2x+y)z) and (\lambda x.(\lambda y.2x+y)) z, which reduce to \lambda x.2x+z and \lambda y.2z+y respectively, would be much less confusing. (It may be impossible to make lambda calculus easy to understand, but we can at least not actively make it more difficult.) Nloveladyallen (talk) 22:33, 2 March 2021 (UTC)
thread_title:  Confusingly written example 

message: A search directed me to a lambda calculus wikibook. There was only a very wrong short intro with concepts borrowed from some not very formal lisp book. I wrote something with the purpose make it clear that many of what was written was wrong because the lambda calculus is important as a foundation of computing theory. Unfortunately I have no time to work on that enterprise. Maybe this article could be copied in wikibooks to be transform it in a lambda calculus book. I did not check if there were previous attempts to write such wikibook. --User:2806:106e:b:31b1:3a5f:db9e:42bd:b4bd 00:51, 15 August 2022 (UTC)
thread_title:  someone lost in space started a lambda calculus wikibook; can someone start to turn this article into a wikibook 

message: From the talk page, it seems like there have been efforts in the past to turn this article into something that is actually helpful as an introduction to the subject that were overriden in favor of the previous unhelpful versions.
This is just a reminder that the current introduction is circular nonsense that only makes sense if a reader is already fully aware of what all of the terms and syntax mean. It should absolutely be rewritten for normal humans, at maximum to a high school reading level. You can get into the circular terminology deeper in the article but the lead, at least, should simply express the general concepts in a way that can be understood by complete neophytes. — LlywelynII 00:59, 21 October 2022 (UTC)
replies: text: When attempting to answer the good faith question below, I saw that Simply typed lambda calculus#Syntax has the gist of what I was trying to say. --Ancheta Wis    (talk  | contribs) 15:09, 23 November 2022 (UTC)
thread_title: Intro

message: What is a capture? 2402:3A80:1A42:12E8:0:0:4141:250E (talk) 07:26, 23 November 2022 (UTC)
replies: text: When a variable x is highlighted in a lambda expression (λ x.B), and B is completely general, then x can be freely chosen (i.e. free to mean anything you like in B). x can be renamed to anything else. But if B contains a + sign, or other operator such as parenthesis, then x is no longer free.  In that case x has been bound by some mathematical operator (e.g.  captured by a + sign, or other operator) which constrains the meaning of the expression B: a + sign in expression B constrains those subexpressions with x. See SECD_machine#Landin's_contribution for avoiding variable capture. --Ancheta Wis    (talk  | contribs) 14:47, 23 November 2022 (UTC)
thread_title:  Computer science 

message: *
*
*
*
*
*
Anas1712 (talk) 16:56, 3 April 2023 (UTC)
replies: text: I suggest adding them to Lazy evaluation (target of call-by-need) or maybe expanding the discussion I wrote in Reduction_strategy#Call_by_need_reduction. This article is quite big already and there's not really a good place for it. Mathnerd314159 (talk) 20:41, 11 May 2023 (UTC)
thread_title:  Adding some references 

message: @WillNess, please refer to (Selinger 2008) for his explanation of the scope of parentheses. Basically Selinger is trying to minimize the use of parentheses, but that does not mean that lambda calculus has no notion of scope, because Selinger is talking about the outermost level of parentheses. --Ancheta Wis    (talk  | contribs) 22:04, 12 May 2023 (UTC)
replies: text: I apologize that it took me some time to get here. I'm reading through the responses now. WillNess (talk) 10:24, 21 May 2023 (UTC)
thread_title:  Parentheses 

message: One reason there are many different typed lambda calculi has been the desire to do more (of what the untyped calculus can do) without giving up on being able to prove strong theorems about the calculus.
''
should be 
what the typed calculus can do Federicolo (talk) 19:08, 2 October 2023 (UTC)
replies: text: No, this is right, the untyped lambda calculus is more powerful. For example, one can easily write the Y combinator in untyped lambda calculus, whereas many typed lambda calculi (such as the simply typed lambda calculus) do not allow it. Mathnerd314159 (talk) 01:41, 3 October 2023 (UTC)
replies: text: Ok I agree with you now: I misinterpreted the sentence Federicolo (talk) 16:14, 13 October 2023 (UTC)
thread_title:  typo in a sentence 

message: The section "Functions that operate on functions" contains a discussion on the identity and constant functions, but fails to use them to illustrate the point of the section - functions being used as input or output. VeeIsMe (talk) 15:55, 4 November 2023 (UTC)
replies: text: I added function composition. The whole section is a mess; I tried to clean up a little bit. - Jochen Burghardt (talk) 09:44, 5 November 2023 (UTC)
thread_title:  "Functions that operate on functions" feels incomplete