meta-cedille
lambdalisp
| meta-cedille | lambdalisp | |
|---|---|---|
| 1 | 3 | |
| 55 | 219 | |
| - | - | |
| 7.5 | 4.4 | |
| 4 months ago | about 1 year ago | |
| Agda | Common Lisp | |
| MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
meta-cedille
-
Any small/simple proof languages?
If you're interested in something that's small, consistent and being able to prove a reasonable amount of things you might be interested in Cedille or my variation of it, Meta-cedille.
lambdalisp
-
Discussion Thread
source code here, i am not genius enough to understand the code-calculus conversion
- Lambdalisp: A Lisp interpreter written in untyped lambda calculus
-
Show HN: Lambda-8cc – An x86 C compiler written in untyped lambda calculus
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
What are some alternatives?
Kind - A next-gen functional language
trivial-toplevel-prompt - Portability library to customize CL implementations' REPL prompt.
Formality - A modern proof language [Moved to: https://github.com/kind-lang/Kind]
lambdacraft - Common Lisp DSL for building untyped lambda calculus expressions
coq - Coq is a formal proof management system. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.
AIT - Algorithmic Information Theory, using Binary Lambda Calculus
Kind - A next-gen functional language [Moved to: https://github.com/Kindelia/Kind2]
write-you-a-haskell - Building a modern functional compiler from first principles. (http://dev.stephendiehl.com/fun/)