3 ms·
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).
by grumpyprole 2y ago
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).
- eternityforest 2y agoActually 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.
- kazinator 2y agoL-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.
- grumpyprole 2y agoYes 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.
- kazinator 2y agoMore 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.
- deleted 2y ago[deleted]