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

An agent in 100 lines of Lisp

thebeach.dev

Post reply on HN
Print view View original

61–70 of 84 posts

Re: An agent in 100 lines of Lisp

#61

Post by gf000 »

galaxyLogic wrote: post #8
goranmoomin wrote: post #7

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structure…

A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. Because Lisp syntax is so much simpler than that of JavaScript etc. it is much easier to avoid errors when generating co…

Well, then ad absurdum it would be easier to just output a bunch of 0s and 1s, right?

The same goes for "just a list of nested lists", sure it is easy to produce it, and for trivial examples it may actually be easy, but for more complex and realistic problems lack of "higher order" structure is a negative!

For something like JavaScript, you can just have a language-native AST object with a few helper functions and then can just call "addFunction" on it with proper arguments so that the API shape validates plenty of properties of your output.

Re: An agent in 100 lines of Lisp

#62

Post by gf000 »

ignoreusernames wrote: post #38
goranmoomin wrote: post #7

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structure…

> Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify I think a more accurate description is that lisp code is just cons cells and cons cells is both how we write the code and how the runtime itself implements lists. So there’s basically no distinction between a lisp list and the text representation of the source. Rust and its macros is a different situation bec…

But this is just not true. An utf8 string is most definitely not a bunch of cons cells. Having a one-to-one correspondence is not the same thing, and one might argue that a rust code snippet and the corresponding AST object is just as arbitrarily far apart with a clean one-to-one correspondence.

So like, what's the material difference between the two? You have a parse and an eval in both cases

Re: An agent in 100 lines of Lisp

#63

Post by gf000 »

TacticalCoder wrote: post #41
goranmoomin wrote: post #7

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structure…

> Eval, on the other hand, that’s more of a capability that comes from Lisp’s runtime, which used to be unique when Lisp was thriving, but not anymore — JS, Python, Ruby, all of the runtime-based languages have an eval function. And it's good we have those for troubleshooting but those eval still offer nowhere near the power of a Lisp REPL. > and I am not sure how having eval can be argued as Lisp being the language…

How is that different from other languages that have proper repls? Lisps don't really give you much here, if the language can parse itself and can eval it, you have the sufficient primitives.

What helps is how "small" the hot reloaded parts can get - lisps are good here due to a lot of functions and not much shared state. But that is again, not something specific to lisps, neither are they the best at it - there are far purer FP languages for example

Re: An agent in 100 lines of Lisp

#64

Post by gf000 »

mvc wrote: post #43
goranmoomin wrote: post #7

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structure…

Does eval in these other languages evaluate ASTs or strings? It makes a difference.

eval(parse(yourString))

No it doesn't

Re: An agent in 100 lines of Lisp

#65

Post by kazinator »

> Symbolic AI lost.

Symbolic AI lost? At what, surely not chess?

A symbolic AI solution to a problem requires vastly less energy. And is deterministic; you can cover it with expected input/output pair regression test cases.

Re: An agent in 100 lines of Lisp

#66

Post by ijk »

gf000 wrote: post #61
galaxyLogic wrote: post #8

Earlier quoted context omitted.

A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. Because Lisp syntax is so much simpler than that of JavaScript etc. it is much easier to avoid errors when generating co…

Well, then ad absurdum it would be easier to just output a bunch of 0s and 1s, right? The same goes for "just a list of nested lists", sure it is easy to produce it, and for trivial examples it may actually be easy, but for more complex and realistic problems lack of "higher order" structure is a negative! For something like JavaScript, you can just have a language-native AST object with a few helper functions and th…

Except you can express the higher order structure in s-expressions too, and using an AST usually means expressing it as a different syntax than the other parts of your program.

Or maybe I've just been sleeping on the power of Javascript AST.

Re: An agent in 100 lines of Lisp

#67

Post by ijk »

zingar wrote: post #56
goranmoomin wrote: post #10

Earlier quoted context omitted.

> A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. > Because Lisp syntax is so much simpler than that of JavaScript etc. it is much easier to avoid errors when generatin…

Now that you mention it, Claude has had trouble at times with balancing brackets in the elisp I have it write. Yet I still had the idea that LLMs should be better at lisp than other languages. A fascinating contradiction, thanks for pointing this out.

Yeah, unfortunately "LLMs are bad at counting" seems to apply to counting parentheses.

With modern tool calling I wonder if a better way to go about it is for the LLM to express the program changes as a function or otherwise use an editor that auto-balances parens. There's a lot of relatively simple tooling that makes it easier to write in a Lisp. The languages tend to lend themselves to being straightforward to check like that.

What's special about Lisp's repl is that it's perfectly possible to construct your entire program in the repl, testing each addition live as you write it. (Many Lisp-focused editors assume you'll want to do this, such as Emacs making it easy to run the interpreter on a single function in a file.) That tooling is lost if you just try to one-shot the file, and before 2026 the majority of LLMs originally just tried to one-shot every file.

But, just like a lot of early LLMs had huge problems with whitespace and numbers because the tokenization was taking efficiency shortcuts that made sense for text but absolutely wrecked code syntaxe, I wonder if the current optimizations are badly formatted for Lisp.

At the very least, using a varient like Clojure that also uses [] and {} in addition to () might help.

Re: An agent in 100 lines of Lisp

#68

Post by ijk »

kazinator wrote: post #65

> Symbolic AI lost. Symbolic AI lost? At what, surely not chess? A symbolic AI solution to a problem requires vastly less energy. And is deterministic; you can cover it with expected input/output pair regression test cases.

Technically the current best chess engine is a neurosymbolic hybrid.

But I have found that sometimes the best use of an LLM is to write code for symbolic AI.

Re: An agent in 100 lines of Lisp

#69

Post by gf000 »

ijk wrote: post #66
gf000 wrote: post #61

Earlier quoted context omitted.

Well, then ad absurdum it would be easier to just output a bunch of 0s and 1s, right? The same goes for "just a list of nested lists", sure it is easy to produce it, and for trivial examples it may actually be easy, but for more complex and realistic problems lack of "higher order" structure is a negative! For something like JavaScript, you can just have a language-native AST object with a few helper functions and th…

Except you can express the higher order structure in s-expressions too, and using an AST usually means expressing it as a different syntax than the other parts of your program. Or maybe I've just been sleeping on the power of Javascript AST.

So can you in binary!

And that's more of a library ergonomics question how nice it is. There are plenty of other languages with nice ASTs and `eval`, and that's the only ingredient you need.

Re: An agent in 100 lines of Lisp

#70

Post by Zambyte »

zingar wrote: post #55
galaxyLogic wrote: post #8

Earlier quoted context omitted.

A Lisp program that writes a Lisp program really just needs to produce a list of (nested lists) of tokens. A JavaScript program that writes a javascript program needs to generate a string that is syntactically valid JavaScript code. That is a much bigger task than just constructing a (nested) list. Because Lisp syntax is so much simpler than that of JavaScript etc. it is much easier to avoid errors when generating co…

I haven’t seen an LLM generate syntactically invalid code in any language in … a year? So I don’t know if “more likely to be syntactically valid” is a good enough selling point. But maybe I’m interpreting you too narrowly?

I take it you never run models locally then? Local models that can run on reasonable consumer hardware have gotten to the point of being very useful, but they still occasionally are tripped up with syntax errors. Especially if you quantize the model and KV.
Post reply on HN