Live data from Hacker News

Lisp in fewer than 200 lines of C

carld.github.io

71–80 of 108 posts

Re: Lisp in fewer than 200 lines of C

#71
post #65

Toward the end of `print_obj()`, we see: if (is_pair(cdr(ob))) { printf(" "); print_obj(cdr(ob), 0); } How could this `if` statement ever evaluate to false? We already verified that `cdr(ob) != 0`, and the CDR can never be a plain old string, so isn't this `if` superfluous?

I don't know about this implementation in particular, but in general a cons cell is just an object with two slots in it. You can use it to represent a list (by putting another cons or nil in the cdr), but you can also use it to represent other things. For example, a pair, by putting an arbitrary object in the car and cdr. This is a pretty common technique, see "a-list" for one application.

Re: Lisp in fewer than 200 lines of C

#72
post #33

Writing 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.

Or Brainfuck. It's fun and only takes half an hour or so.

Re: Lisp in fewer than 200 lines of C

#73

That'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/ .

Have you taken a look at ClojureScript? You might find it interesting.

Re: Lisp in fewer than 200 lines of C

#74
Awesome article, thanks for that. As someone who almost never even looks at C code, this was very understandable with the inline comments.

What's the reason for using macros instead of real functions? Is this an optimization because macros get inlined at compile time? Does this really bring a lot of value?

Re: Lisp in fewer than 200 lines of C

#76

Oof, all the macros are broken: #define is_space(x) (x == ' ' || x == '\n') #define is_parens(x) (x == '(' || x == ')') Should be #define is_space(x) ((x) == ' ' || (x) == '\n') #define is_parens(x) ((x) == '(' || (x) == ')') Probably doesn’t matter in practice for this. It could end up being a nasty source of bug later on in the project.

I'd argue that is_space() should be isspace(), the standard from . Pretty sure it wouldn't make the semantics of the language worse, but it's one less wheel re-invented and makes the code a smidgen easier to read since there's one less concept to learn in it. Also one less thing to debug ...

Re: Lisp in fewer than 200 lines of C

#77
post #33

Writing 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…

7 typing and Hindley-Milner inference

Re: Lisp in fewer than 200 lines of C

#78
Things that bugs me: cast to (long) when they should use intptr_t.

EDIT: And gettoken() should check against buffer: index EDIT 2: And I'd store the tag in a separate variable, because bit abuse in a pointer is plain and simply asking for problems.

Re: Lisp in fewer than 200 lines of C

#79

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. https://github.com/marcpaq/arpilisp

Since this is written in assembly is it much faster than a C version since this one can manage its own stack frames and stack variables and such? I always imagined that’s the case and that a lisp implemented fully in assembly would be the trick to a super fast lisp that can complete with Go.

An interpreter written in assembly is still an interpreter. Yes, it may have control over stack frames. But so does a compiler, and the code generated by a compiler doesn't incur interpretation overhead. If you want performance, compliation is the way to go. And that's what fast Lisps do.

Re: Lisp in fewer than 200 lines of C

#80
post #65

Toward the end of `print_obj()`, we see: if (is_pair(cdr(ob))) { printf(" "); print_obj(cdr(ob), 0); } How could this `if` statement ever evaluate to false? We already verified that `cdr(ob) != 0`, and the CDR can never be a plain old string, so isn't this `if` superfluous?

Nope. It still can be an atom. Only if it's a pair (i.e. a cons with two cells, not just one) it prints the next.
Post reply on HN