I was deceived by a glimmer of false hope: a page full of ). Alas, I then glanced at the page number---far short of the 18000+ goal.
My favorite is still INTERCAL [1] since the result is actually useful, and it ranks high on the levity meter.
λ 1 ((λ 1 1) (λ λ λ λ 2 (4 4) (λ 1 4 2))) (λ λ 1)
let nil = \n c. n;
let cons = \hd tl n c. c hd tl;
let map = ...;
body
(\nil cons map. body) (\n c. n) (\hd tl n c. c hd tl) (...)
All the lambda terms on that page were manually optimized for minimum blc size. This C compiler term on the other hand was produced by several layers of translation, making it rather large. I suspect that a handwritten version could be written in a thousand pages of lambdas...
Btw, while it makes a nice stress test for LaTeX, I find it a bit odd that "pages of PDF" is the preferred way to express the size of the lambda binary:-)
Looking forward to seeing the binary lambda calculus back-end added to ELVM.
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
So like C -> ELVM IR -> lambda calculus?
If so, it seems like 8cc is doing most of the heavy lifting
Nice
Absolutely impressive project !
Just the kind of ridiculous brilliance I needed at the end of a hard week. Bravo!