If you like this, you might like Lisp interpreter written in assembly in a single file. It is one of the best commented code ever written imo.
Lisp in fewer than 200 lines of C
31–40 of 108 posts
Re: Lisp in fewer than 200 lines of C
#32This is more of historical interest than of technological interest...
I think you are mistaken. There is much to learn from implementations such as this, and the techniques used form the basis of much more complex systems. The technology remains very relevant.
FWIW, I didn't downvote you, as I don't downvote someone simply because I believe they're wrong, or because I disagree with them.
Re: Lisp in fewer than 200 lines of C
#33Writing your own Lisp-ette is a brilliant evening or weekend project, regardless of the language. It's some of the simplest non-toy parsing you can attempt, a bit of light data structure work, and understanding eval/apply is 80% of the work in implementing it. I would highly recommend anyone to have a go, and try not to follow existing code too closely: figure out the problems in your language of choice.
The post identifies some of it's own weaknesses (memory handling, errors), which are quite C specific. Or at least easier to handle in other languages, where you can punt those issues to the host language runtime. But it will be a fun extension to fix them (a job for the second evening / weekend of coding ;) )
But, imho, the beauty of writing a Lisp is that there are a bunch of things you can do from there, some more difficult, but several are achievable step-by-step in a day or a few days each. I'd first add a few special forms more than the OP (quote, if, progn, math operations), then my suggestions:
1. Defining names (if you haven't already), both let and define special forms.
2. Lambdas.
3. Tail call optimisation (I suggest this not because it's an optimisation, this Lisp doesn't need optimising, but because TCO is a bite-sized extension.)
4. Lexical scoping of lambdas.
5. Continuations. call/cc
6. And if you're really brave (or skilled, or just masochistic), macros.
I was encouraged to do this as a new grad student, and it was one of the most fun and educational experiences I remember. I didn't get as far as macros back then, but implementing call/cc was a definite pivot point in my programming competence.
Re: Lisp in fewer than 200 lines of C
#34Earlier quoted context omitted.
"Other times the program will keep running with incorrect results. Many such issues represent exploitable bugs." None of which matter if it's a prototype, running on a developers machine. If you want memory safety you run the program through valgrind anyway with a large input dataset. And write unit tests. And integration tests. And so on. The baggage of production quality software development environment is so high…
I don't know if you noticed this but C hackers are a minority on here. Thus it's not unreasonable to think people get an impression of how C is done from submissions here. We owe it to the craft to serve as good examples. It's not as burdensome as you suggest.
I see your point, but respectfully disagree that an incomplete implementation should stop a submitter from sharing his or her discoveries. This is an aesthetic position - I think interesting ideas are more important than clean implementations (It is left as an exercise to the reader... is an ok position, IMO).
Re: Lisp in fewer than 200 lines of C
#35Writing your own Lisp-ette is a brilliant evening or weekend project, regardless of the language. It's some of the simplest non-toy parsing you can attempt, a bit of light data structure work, and understanding eval/apply is 80% of the work in implementing it. I would highly recommend anyone to have a go, and try not to follow existing code too closely: figure out the problems in your language of choice. The post ide…
If you go with (hygenic) fexprs instead of macros, they're both easier to implement and more expressive, at the expense of performance.
Check out John Shutt's thesis for more information on hygenic fexprs: https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr...
Re: Lisp in fewer than 200 lines of C
#36If Lisp is so easy so implement, is it also easy to learn? (I am familiar with Haskell)
Re: Lisp in fewer than 200 lines of C
#37While this is very cool, it has at least one buffer overflow vulnerability. There is no bounds checking in gettoken().
Also, the talk about pointers being aligned to "8 bit boundaries" I think means 8 byte boundaries. Memory is not bit-addressable (at least, not in C, on anything popular).
But I don't mean to detract from the project! It is very cool nonetheless :)
Re: Lisp in fewer than 200 lines of C
#38Writing your own Lisp-ette is a brilliant evening or weekend project, regardless of the language. It's some of the simplest non-toy parsing you can attempt, a bit of light data structure work, and understanding eval/apply is 80% of the work in implementing it. I would highly recommend anyone to have a go, and try not to follow existing code too closely: figure out the problems in your language of choice. The post ide…
If you go with (hygenic) fexprs instead of macros, they're both easier to implement and more expressive, at the expense of performance. Check out John Shutt's thesis for more information on hygenic fexprs: https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr...
Thanks for the tip. If it wasn't the end of the weekend, I'd be tempted to break out emacs.
Re: Lisp in fewer than 200 lines of C
#39Writing your own Lisp-ette is a brilliant evening or weekend project, regardless of the language. It's some of the simplest non-toy parsing you can attempt, a bit of light data structure work, and understanding eval/apply is 80% of the work in implementing it. I would highly recommend anyone to have a go, and try not to follow existing code too closely: figure out the problems in your language of choice. The post ide…
I found none of these particularly difficult. (I've never attempted 3. or 5. though.) Functional values, however, are difficult. They work effortlessly in interpreted code, but in compiled code you're faced with the upwards funarg problem: https://en.wikipedia.org/wiki/Funarg_problem#Upwards_funarg_...
A solution is needed if you want lazy evaluation.
Re: Lisp in fewer than 200 lines of C
#40Writing your own Lisp-ette is a brilliant evening or weekend project, regardless of the language. It's some of the simplest non-toy parsing you can attempt, a bit of light data structure work, and understanding eval/apply is 80% of the work in implementing it. I would highly recommend anyone to have a go, and try not to follow existing code too closely: figure out the problems in your language of choice. The post ide…
I found none of these particularly difficult. (I've never attempted 3. or 5. though.) Functional values, however, are difficult. They work effortlessly in interpreted code, but in compiled code you're faced with the upwards funarg problem: https://en.wikipedia.org/wiki/Funarg_problem#Upwards_funarg_... A solution is needed if you want lazy evaluation.
How did you do lambdas and lexical scoping without 'functional values'?