Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp in fewer than 200 lines of C

carld.github.io

Post reply on HN
Print view View original

91–100 of 108 posts

Re: Lisp in fewer than 200 lines of C

#91

Post by klmr »

ci5er wrote: post #70
_sdegutis wrote: post #67

Earlier quoted context omitted.

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.

LISP was created a long time ago. Assembly was the weapon of choice. Thinking Machines, Symbolics and Macsyma might already say: We did that. But, uh, no.

The first LISP implementation was famously done in machine code, not assembly.

Re: Lisp in fewer than 200 lines of C

#92

Post by klmr »

kindfellow92 wrote: post #68
geofft wrote: post #63

Earlier quoted context omitted.

That still evaluates x twice, which can also be a source of bugs. I usually take one of two approaches: either decide that this is a weekend hack and using the macros whenever the expansion isn't obvious in my head is a sign of too much complexity, or use this GCC extension: #define is_space(x) ({ typeof(x) y = x; y == ' ' || y = '\n'; }) (Or in this case, turn it into an actual function and let the compiler figure o…

GCC extensions make my brain hurt :( Should just use C++ at that point: template bool is_space(const T & x) { return x == ‘ ‘ || x == ‘\n’; }

The function can be trivially implemented in C, since you don’t need a generic input argument type. No idea why OP chose macros in the first place.

Re: Lisp in fewer than 200 lines of C

#93

Post by klmr »

mweibel wrote: post #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?

> Does this really bring a lot of value?

In this particular case, none whatsoever. It’s egregious abuse of macros.

Re: Lisp in fewer than 200 lines of C

#94

Post by Wohlf »

piinbinary wrote: post #15

After reading Peter Norvig's post about a lisp implementation [0], I decided to write one in Python. I got something working in 65 lines [1] [0] http://norvig.com/lispy.html [1] https://gist.github.com/jmikkola/b7c6c644dff1c07891c698f0a52...

Thanks for this, I recently did the same and it's nice to have others work to compare to.

Re: Lisp in fewer than 200 lines of C

#95

Post by z29LiTp5qUC30n »

nielsbot wrote: post #83
akashakya wrote: post #31

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

Someone once suggested to me the easiest way to "bootstrap the world" is to write a Forth implementation in assembly, and then write your Lisp in Forth.

as there is a project aiming to "bootstrap the world" https://savannah.nongnu.org/projects/stage0/ and they hand wrote a FORTH http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/f... and a compacting garbage collecting lisp http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/l...

and their opinion was that it was easier to do the lisp than it was to do the FORTH. Although right now they are trying to improve their C Compiler prototype https://github.com/oriansj/M2-Planet before they convert it to assembly

Re: Lisp in fewer than 200 lines of C

#96

Post by raldi »

rurban wrote: post #80
raldi wrote: 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.

Even if that were possible (and with this codebase, I don't think it is), I don't see any code in this function that would print the atom in such a case. It seems like it would just print nothing.

Re: Lisp in fewer than 200 lines of C

#100

Post by DonaldFisk »

chrisseaton wrote: post #57
DonaldFisk wrote: post #39

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

> They work effortlessly in interpreted code, but in compiled code you're faced with the upwards funarg problem No it's not about interpreted or compiled. It's about using the native stack or a heap for stack frames. Compiled code and interpreters can both use either, so that's orthogonal.

Yes, to solve the upwards funarg problem you can't rely on a single stack. The problem is that using the heap for everything instead comes with a heavy computational cost, and using the heap only when you need it means you need to identify those circumstances, which isn't trivial.
Post reply on HN