4

The Structure and Interpretation of Computer Programs book I've been reading presents Church numerals by defining zero and an increment function

zero: λf. λx. x
increment: λf. λx. f ((n f) x)

This seemed pretty complicated to me and it took me a really long time to figure it out and derive one (λf.λx. f x) and two (λf.λx. f (f x)).

Wouldn't it be much simpler to encode numbers this way instead, with zero being the empty lambda?

zero: λ
increment: λf. λ. f

Now it's trivial to derive one (λ. λ) and two (λ. λ. λ), and so on.

This seems like a much more immediately obvious and intuitive way to represent numbers with lambdas. Is there some problem with this approach and thus a good reason why Church numerals work the way they do? Is this approach already attested?

Peter Olson
  • 139,199
  • 49
  • 202
  • 242
  • I'm not sure I see what's wrong with this question. Can somebody explain? – Peter Olson Jan 16 '12 at 00:56
  • I didn't cast a close vote, but possibly folks feel its a better fit on cstheory or something? – joran Jan 16 '12 at 01:04
  • CSTheory is for research level questions. This one is probably too elementary. – Peter Olson Jan 16 '12 at 01:29
  • I think the title could be cleaned up to sound more objective and in-line with the remainder of the post, which would make it a better question overall. –  Jan 16 '12 at 01:32
  • I agree that this doesn't belong on CS Theory SE, but it's not exactly a specific programming problem with code, either. Even so, good enough for a +1 from me. – Pops May 01 '12 at 06:32

2 Answers2

8

Your encoding (zero: λx.x, one: λx.λx.x, two: λx.λx.λx.x, etc.) makes it easy to define increment and decrement but beyond that, it becomes pretty tricky to develop combinators for your encoding. For example, how would you define isZero?

An intuitive way to think about the Church encoding is that a numeral n is represented by the action of iterating n times. This makes it easy to develop combinators like plus by just using the iteration encoded in the number. No need for fancy combinators for recursion.

In the Church encoding, each number has the same interface: it takes two arguments. While in your encoding, each number is defined by the number of arguments it takes, which makes it really tricky to operate uniformly on.

Another way to encode numerals, would be to think of numbers as n = 0 | S n, and use a vanilla encoding for unions.

namin
  • 37,139
  • 8
  • 58
  • 74
0

The proposed syntax for numerals is not valid in lambda calculus, whereas Church numerals are indeed valid constructions in lambda calculus. So that's a possible reason why Church numerals are the way they are - the number encoding must adhere to the lambda calculus' definition in a way that also permits further operations also defined in lambda calculus (increment, for example) to operate over the encoded numbers.

Óscar López
  • 232,561
  • 37
  • 312
  • 386
  • I don't think I understand, what about it is invalid in lambda calculus? Are empty lambdas not permitted for some reason? If that's the problem, it would be trivial to give it a dummy argument that it basically ignores and make it non-empty. – Peter Olson Jan 16 '12 at 01:32
  • 1
    Take a look at the [grammar](http://www.csse.monash.edu.au/~lloyd/tildeFP/Lambda/Ch/01.Calc.html) (not the extended, only the basic). No matter what encoding you choose for numbers, it must respect that grammar - something that your proposed encoding doesn't do – Óscar López Jan 16 '12 at 01:36
  • That really doesn't explain. I'm asking you *what part* my encoding violates the grammar? It seems the only form in mine that differs from the other is the empty lambda, which can be trivially replaced with `λx.x`. – Peter Olson Jan 16 '12 at 01:52
  • 1
    It _does_, for example according to the grammar this is not a valid lambda function `λ.λ` (that's the number 1 according to your encoding). On the other hand, `λf.λx. f x` is perfectly valid, and that's the representation [chosen](http://en.wikipedia.org/wiki/Church_encoding#Definition) for the number 1. Understand this: you can't chose an arbitrary string of symbols, they have to be valid under the grammar of the calculus, and yours aren't – Óscar López Jan 16 '12 at 02:01
  • Replace every instance of the empty `λ` with `λx.x` and you get something that works with the grammar, but slightly more unwieldy. Zero: `λx. x` One: `λx. λx. x` Two: `λx. λx. λx. x`, etc. The approach is identical. Your answer doesn't really touch my encoding approach, you're just complaining about my notation, which accords with the grammar after one simple substitution. – Peter Olson Jan 16 '12 at 02:26
  • Download the [code](http://www.eopl3.com/code.html) for "Essentials of Programming Languages", in the first chapters of that book there's an interpreter for lambda calculus, try your encoding and see if it works. It won't. You just don't get grammars, that's all. – Óscar López Jan 16 '12 at 02:49
  • 1
    I *do* understand grammars: I've even written code parsers. I'm getting a little annoyed that you keep harping on the notation I use which, after some simple substitution, is valid according to the grammar you linked to. If you like, I can change my notation to be more conventional and explain my approach using it instead, but your answer, as it stands, doesn't really address my question at all. – Peter Olson Jan 16 '12 at 03:09