See also Ben Lynn's implementation[1] in about 100 lines of Haskell. Admittedly it's not a totally fair comparison because it's relying on Haskell's runtime, but it's still an excellent demonstration of Haskell's power and expressiveness compared with a lower level language.
Lisp in fewer than 200 lines of C
41–50 of 108 posts
Re: Lisp in fewer than 200 lines of C
#42Writing 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…
Another fun one is a Forth interpreter. I tried to make one in Rust once, I can't say I actually succeeded but it's fun to tinker with. It is simple enough that you can probably write a bad one in assembly without that much assembly knowledge.
Re: Lisp in fewer than 200 lines of C
#43That's fun. Here's Jisp, my Lisp implementation in a tiny bit of JavaScript. It supports declaring functions, interop with JavaScript, quoting a list, variable arg lists, and more: http://www.ducklet.com/jisp/.
Re: Lisp in fewer than 200 lines of C
#44Earlier quoted context omitted.
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'?
Presumably by implementing only the simpler "downwards" funargs: the ability to pass functions into a function scope but never return them.
Re: Lisp in fewer than 200 lines of C
#45Earlier quoted context omitted.
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'?
That's explained in
https://en.wikipedia.org/wiki/Funarg_problem#Downwards_funar...
In addition to return address and dynamic link, you need to store a static link in each stack frame.
Re: Lisp in fewer than 200 lines of C
#46Lisp with full lexical closures in ~100 lines of Python:
http://www.flownet.com/ron/lisp/l.py
The interpreter itself is 48 lines.
Re: Lisp in fewer than 200 lines of C
#47See also Ben Lynn's implementation[1] in about 100 lines of Haskell. Admittedly it's not a totally fair comparison because it's relying on Haskell's runtime, but it's still an excellent demonstration of Haskell's power and expressiveness compared with a lower level language. [1]: https://crypto.stanford.edu/~blynn/lambda/lisp.html
To be fair, it is not just that Haskell is a "high-level language", but that it is a language in the ML family of languages. ML means "Meta Language" and was specifically designed to be used to implement (other) languages.
Re: Lisp in fewer than 200 lines of C
#48Writing 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.
5 is do-able by an undergrad, though the first time you encounter the concept it can be difficult to grapple how you would implement it.
Re: Lisp in fewer than 200 lines of C
#49If 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. https://github.com/marcpaq/arpilisp
Another small lisp implementation: http://piumarta.com/software/lysp/
Also, another, more interesting Lisp by the same author: (http://piumarta.com/software/maru/). Maru is basically a lisp where some of the core functions like eval and apply are extensible from user code. There's basically a global map of types to evaluators and applicators, with some functions for you to register your own types and get the evaluation behavior you want.
Re: Lisp in fewer than 200 lines of C
#50This 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.
While I agree that it's not just historical interest - there's still much that can be learned from Lisp - this implementation is certainly not the place to learn it. There's no garbage collection, which is really the biggest concern of a proper lisp implementation in a language like C. Without GC, it's a gimmick implementation. There's no practical use for it.