Rendered at 12:13:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
RedRackham 3 hours ago [-]
Well done!
I wrote a wee lambda calculus interpreter to test out the book forms. I did cheat a wee bit and added:
def <name> = <exp> ==> substitution of <exp> for <name> before evaluation
if <exp1> then <exp2> else <exp3> fi ==> ((<exp1> <exp2>) <exp3>)
to make things more readable.
I think a few folk have got as far as implementing lists and recursion, but you're the first dynamic type implementer I've come across.
I think lambda calculus is fun. My book is about functional programming, and so isn't much use for theory, for which I recommend Barendregdt's "The Lambda Calculus. Its Syntax and Semantics".
Best wishes
Greg Michaelson
rsrsrs86 14 hours ago [-]
This is uninteresting, because 1) you could just share your prompt: “implement Greg Michaelsons book in racket” 2) you added nothing to it 3) you skipped about everything that is interesting to study when learning the lambda calculus
kjs3 12 hours ago [-]
I'm printing this out and mounting it on the wall. Well played, my friend...well played.
kserrec 11 hours ago [-]
1. I started all_the_lambdas first and in making it, I only borrowed a single idea from Michaelson that was new to me, the idea of type tags. Also I'd estimate that 99% of that original project was done by hand a couple years ago, no LLMs (as I recall, I think I wanted to test chatpgt for just a couple specific things a few weeks into making it then, the division and subtraction algorithms for my binary digit list encodings of natural numbers and the best model then couldn't even figure out the division algorithm anyway so I had to do it myself!)
And for Attalambda I only borrowed one more idea from Michaelson that was new to me, which was his empty list encoding (I originally just used false/zero in my first project, but his pair of empty list errors idea for nil just seemed better so I took that proudly when I remade that original project into this one). And I am not at all shy about the fact that I took inspiration from him and you can see that if you look at git history or my plan documents. Neither am I shy about the fact that I used LLMs in building AttaLambda (and I did so a lot!), but basically all the ideas came from me or just common knowledge about lambda calculus.
Anyway, a one-shot project based on that prompt you suggested does sound very interesting. Please give it a go and let me know how far you get and what it looks like. I genuinely want to see the results.
2. As for what wasn't adopted from Michaelson, well it's basically everything else in AttaLambda, everything short of the two things I mentioned I borrowed. Although I will admit that I don't think any of the other parts are anything particularly unique individually; it's more in their combination that I think you get something rather unique. for instance, I have a binary digit list encoding of natural numbers which integers and then rational numbers are successively built off of (this is a huge performance boost from Church numerals!), Then there are the Option and Result types, the generalized type checking functions (I struggled with these at first in all_the_lambdas and in further generalizing them in AttaLambda and am very proud of them!), and there's the error propagation mechanism so errors bubble up and gather information along the way.
3. As for skipping what's interesting to lambda calculus, it's a big subject and I've just gotten started! Can you tell me what I've overlooked that you want to see? The goal for me was originally just to play with lambda calculus and keep building whatever struck me personally as interesting at the time (and I succeeded at that!), like building different encodings of numbers and types of numbers, or writing algorithms for lists or search algorithms, or after I started using type tags I explored strong typing versus coercion, and more. This has been really fun for me and I just wanted to share. Idk if I have had more fun coding anything else in my life. And then I thought it would be fun to add the host boundary and make this a real language I could use rather than just a toy and so I went from the all_the_lambdas project to AttaLambda - that's what kicked this all off. I really wanted to see, could I take this pure unary untyped lambda calculus base from this first project and add a tiny boundary to let it become an actually usable (although almost entirely impractical) language? What would you have done instead?
I wrote a wee lambda calculus interpreter to test out the book forms. I did cheat a wee bit and added:
def <name> = <exp> ==> substitution of <exp> for <name> before evaluation
if <exp1> then <exp2> else <exp3> fi ==> ((<exp1> <exp2>) <exp3>)
to make things more readable.
I think a few folk have got as far as implementing lists and recursion, but you're the first dynamic type implementer I've come across.
I think lambda calculus is fun. My book is about functional programming, and so isn't much use for theory, for which I recommend Barendregdt's "The Lambda Calculus. Its Syntax and Semantics".
Best wishes
Greg Michaelson
And for Attalambda I only borrowed one more idea from Michaelson that was new to me, which was his empty list encoding (I originally just used false/zero in my first project, but his pair of empty list errors idea for nil just seemed better so I took that proudly when I remade that original project into this one). And I am not at all shy about the fact that I took inspiration from him and you can see that if you look at git history or my plan documents. Neither am I shy about the fact that I used LLMs in building AttaLambda (and I did so a lot!), but basically all the ideas came from me or just common knowledge about lambda calculus.
Anyway, a one-shot project based on that prompt you suggested does sound very interesting. Please give it a go and let me know how far you get and what it looks like. I genuinely want to see the results.
2. As for what wasn't adopted from Michaelson, well it's basically everything else in AttaLambda, everything short of the two things I mentioned I borrowed. Although I will admit that I don't think any of the other parts are anything particularly unique individually; it's more in their combination that I think you get something rather unique. for instance, I have a binary digit list encoding of natural numbers which integers and then rational numbers are successively built off of (this is a huge performance boost from Church numerals!), Then there are the Option and Result types, the generalized type checking functions (I struggled with these at first in all_the_lambdas and in further generalizing them in AttaLambda and am very proud of them!), and there's the error propagation mechanism so errors bubble up and gather information along the way.
3. As for skipping what's interesting to lambda calculus, it's a big subject and I've just gotten started! Can you tell me what I've overlooked that you want to see? The goal for me was originally just to play with lambda calculus and keep building whatever struck me personally as interesting at the time (and I succeeded at that!), like building different encodings of numbers and types of numbers, or writing algorithms for lists or search algorithms, or after I started using type tags I explored strong typing versus coercion, and more. This has been really fun for me and I just wanted to share. Idk if I have had more fun coding anything else in my life. And then I thought it would be fun to add the host boundary and make this a real language I could use rather than just a toy and so I went from the all_the_lambdas project to AttaLambda - that's what kicked this all off. I really wanted to see, could I take this pure unary untyped lambda calculus base from this first project and add a tiny boundary to let it become an actually usable (although almost entirely impractical) language? What would you have done instead?