|
|
|
|
|
|
by tromp
1354 days ago
|
|
|
The hint file [1] of my 2012 IOCCC entry provides a nice introduction to the binary lambda calculus that this awesome piece of work runs on. 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. [1] https://www.ioccc.org/2012/tromp/hint.html |
|
|
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