In the early 2000's, Teemu Kalvas created "Lisp 500": 500 lines of C (plus a .lisp file that provides a library and goes as far as featuring a compiler, which works by emitting C).
That is neither here nor there because parsing is a small sub-problem of the overall problem of providing a complete programming language run-time. Lisp500 isn't a "meta-circular" interpreter; it cannot rely on a host Lisp's implementation of things like memory management, I/O streams, hashing, compilation, ...
Shouldn't the title of the article be "500 lines or less - ceval.c written in Python" or "500 lines or less - a python bytecode interpreter written in python"
The original one is just misleading.
It is an interpreter and that's absolutely correct. They could've even said "A vm in Python" because that is a VM, just without JIT etc. The compiler includes a parser usually, but interpreters in the purest sense of the word interpret the semantics of some structure corresponding to the code.
It's not an interpreter of the programming language Python, however. It's a VM for Python bytecode, which is not what most people understand as Python, right?
Well, for one, you will have to implement the memory/system model for the language. It may or may not have access to the host language's "printf" function.
Initially of course, a shortcut way is to leverage as much of the host language's features as possible, then eventually, as you move further into the bootstrap process, you will want to remove reliance on the host language.
I'm a bit put off by your combination of praise and dismissiveness when I think neither are warranted.
This is a pretty standard stack-based virtual machine. It is not particularly elegant, nor is the underlying language designed to be particularly elegant, much less have a monopoly on such. It's designed more for clarity and practicality.
I meant it was impressive that it was so simple to implement the python VM in itself, but becomes less impressive when compared to the simplicity and elegance with which you can do similar feats in other languages. I find that point valid.
Lisp will always be a special case. It's too powerful to give other languages a running. It's not quite the same when the language makes it ridiculously easy to build new languages.
What makes this impressive is the medium of expression, like when an artist blows you away with a Biro drawing.
If someone wrote this in assembly in 500 lines or less (if that's even possible), it would be incredible.
This VM is meant to match Python semantics, including support for keyword arguments with defaults, lexical scope, and exceptions. Neither the original McCarthy Lisp description which qwertyuiop924 praised, nor first Lisp implementation by Russell, supported those features. The latter two features came with Lisp 1.5, whose implementations are much larger than 500 lines. http://www.softwarepreservation.org/projects/LISP .
And that's okay - a language doesn't require those features. And a language without them, like Forth, can be much more compact as a result.
I wasn't intending to praise it, just show that other languages did similar things more elegantly.
Also, in case you weren't reading carefully, I also pointed to Scheme's metacircular evaluator, which implements lexical scope, continuations (of which exceptions are a subset), and can implement defaults with relatively simple extension.
I was curious so looked up McCarthy's paper. Appendix B has code and pseudo code for minimal interpreter. Takes one page. Primitives are easy to code, too. It would surpise me if that took much larger than 500loc to implement.
Lexical scope, in particular, is very easy to implement. Call/cc or exceptions are a bit tougher, but it can be done. And all defaults take is a bit of extension to the lambda. In fact, defaults can be added atop the language with a macros, as can keyword arguments. Macro expanders are a bit harder to write than the functionality itself, however. Especially if you want a good one.
That's certainly true. It's a good point. It also means that if we're discussing the elegance with which a language can be expressed within itself, Lisp is a reasonable comparison to make, to show the maximum elegance with which this can be done.
I didn't say it was the only language that could implement itself elegantly. Admittedly, I've never seen seen a Forth implementation in Forth, so for all I know, it's incredibly ugly. Or so beautiful it could bring tears to the eyes of god. I don't know.
True, you didn't. But you did say it maximized elegance, which means you think a Forth in Forth cannot be more elegant.
In practice, some people adore Forth. Most do not. Some people adore Prolog. Most do not. Relatively more people adore Lisp than either Forth or Prolog.
Such elegance is therefore in the eye of the beholder, not some god.
Forth's elegance is how it well it matches up to most hardware. The inner loop of a Forth interpreter can be as little as a few dozen lines of assembly, and its eval not much longer.
What did you expect me to do? Argue? You made some good points. :-D
Although you do realize the god part was hyperbolic, showing an absurd maximal beauty. I'm not even very religious, it just seemed a fitting representation of such an absurd beauty. I thought that was pretty clear from the context...
No, no I haven't. I know a bit about programming languages, not massive amounts.
Now that you've had some time to stare smugly down your nose at me, my point was that it was a testament to the expressiveness of Python, and the simplicity of the VM that that VM was a reasonable thing to write in 500 lines of python. I also noted that it's sligtly less impressive in light of how Scheme was able to do something similar, but in a significantly more compact manner, as the language was more flexable, and simpler.
I can't find the sources for this.
Incomplete, no .lisp file: http://www.s2.org/~chery/projects/lisp500/
Doesn't connect: http://modeemi.cs.tut.fi/~chery/lisp500/
The most accessible source for this currently seems to be a "lisp5000" project in GitHub: https://github.com/jackpal/lisp5000
This is a derivative work whose C code has been blown up to 1600+ lines.