AIT VS lambdalisp

It is described in https://github.com/tromp/AIT/blob/master/fast_growing_and_co...

A = λxλyλz. x z (y (λ_.z)), which is encoded as bit 0 (left branch), while bit 1 (right branch) encodes prefix application.

[1] https://github.com/tromp/AIT/blob/master/ait/allA.lam

I expect so, as the author is familiar with my tools [1] for doing these optimizations.

[1] https://github.com/tromp/AIT

Haskell is not far from being a layer of syntactic sugar on top of the lambda calculus.

For an example of a non-trivial program, see this binary lambda calculus self-interpreter: https://github.com/tromp/AIT/blob/master/uni.lam

While Goodstein sequences do get really long quite fast, they're not that easy to code. This [1] binary lambda calculus program may be the shortest possible, but still takes 351 bits. Meanwhile, in a mere 215 bits, we can encode a Laver table [2] program that potentially grows so much faster than Goodstein, that it's not even provable in ZFC [3].

[1] https://github.com/tromp/AIT/blob/master/goodstein.lam

[2] https://github.com/tromp/AIT/blob/master/laver.lam

[3] https://codegolf.stackexchange.com/questions/79620/laver-tab...

source code here, i am not genius enough to understand the code-calculus conversion

I actually mentioned your hint file in details.md. Quite a roundabout way to decode its secrets!

I too suspect that writing in lambda's native functional style could save a lot of space. Compiling lisp.c from the ELVM repository generates a code much longer than LambdaLisp [1], which empirically shows that well I believe.

As for the pages of PDF, in mathematical terms, since any variable encodes to weight 1, I believe it would be something close to an encoding that degenerates all De Bruijn indices to 1, or in other words, one that only tries to weigh (or gives larger weight to) the complexity of abstraction depths and applications. Since that erases information about the variable I would guess it's not a universal method for weighing lambda sizes.

In this particular case for LambdaVM programs however, since the memory initialization clause nor the instruction clause never increases the maximum De Bruijn index value, I believe both the BLC size and "lambda page size" approximately grows linearly with the number of instructions, so I thought it would serve as an approximately-off-by-a-factor metric for weighing its size.

As for the ELVM lambda calculus back-end, I'll be sending the pull request very soon!

[1] A Lisp interpreter implemented in lambda calculus: https://github.com/woodrush/lambdalisp