Hacker News Reader

Comment by ufo | Hacker News Reader

I know the author starts the post by saying he won't explain the reasons why he had to write a new Lua interpreter from scratch, but I'm still curious about that. Does anyone know? I dug through some of the links in the post and couldn't find the answer.

View on HN

Yup, as others have mentioned, it's for zb. I originally outlined some background on design goals for this blog post, but the outline for that section was as big as the outline for the rest of the post, so I cut it. I'll probably write that one up as another blog post in the near future. :)

(Also, my pronouns are she/her.)

This is exactly the part I got hung up on, too.

    The exact reasons aren’t important for this blog post, but neither the reference implementation [...] nor the other open source Go Lua intepreters I could find were a good fit for my needs.

I'm intrigued because presumably the shortcomings of the other implementations are important to how they chose to implement Lua here.

It's for zb, a Bazel-inspired build system that uses Lua instead of Starlark (stripped down python).

Zb: An Early-Stage Build System - https://news.ycombinator.com/item?id=41595310 - Sep, 2024 (125 comments)

and the beta announcement was also recently submitted, but without commentary https://news.ycombinator.com/item?id=44290692

Given this is going to be used as a scripting language for a build system, it's possible they are trying to implement a restricted subset of Lua rather than than the full language.

From the article:

    My Lua data types have a notable difference from C Lua: an ability to be “frozen”.

Reply on news.ycombinator.com