Hacker News Reader

It doesn't have to be a crazy amount of work, see Lisp-in-Lisp in the original SCIP book or a lambda calculus interpreter in Haskell (fits on a screen).

View on HN

L-in-L interpreters assume that you already have symbols implemented, memory management implemented, reader and printer implemented, ...

You could spend considerably more time implementing a Lisp dialect's math library than the interpreter. There are a lot of combinations.

Where are the objects, hash tables, exception handling, ...

Of course you can get some of these things from a host language, but someone had to make them.

Yes but my point is that these problems are as hard as we want to make them. For a simple language implemented in C, maybe it's fine to never free any memory until the process quits.

More like, for a simple problem or a sufficiently small instance of a complex problem being solved in C, or a language written in C (simple one or otherwise), maybe it's fine to never free memory until the process quits.

Actually doing anything beyond weekend project complexity with that sort of thing is pretty hard though.

I guess if you have a lot of fairly small ideas with a lot of novelty, I could see the appeal of a new language to express them in.

Reply on news.ycombinator.com