Algebraic data types in Lua (almost) | Hacker News Reader

Algebraic data types in Lua (almost)

mrcjkb.dev

80 pointsmrcjkb9 comments

I think the main concept introduced here is to hand-write what would be the match expression for each union. I've done similar stuff in languages with no ADT's, but without exhaustiveness checking you're left with co-locating the matcher next to the union type and hoping you remember to update it if anything changes.

Good point. I guess that's one of the limitations that comes with a structural type system.

Pretty fascinating stuff. I wasn't aware of the push to do some static annotations in Lua and that seems like a great idea.

I've used at least three bespoke configuration languages where I eventually had to ask "Why isn't this just Lua?" I highly recommend embedding Lua as the first option over writing one's own config language and parser any time someone suggests it.

Absolutely. I built my own DIY thermostat and was spending weeks of free time working on the configuration system for it so that it could do the things I wanted. I thought I had a decent system for it, and then I realized it's a pain in the ass to work with in its JSON format. Rather than find a language that would make the configuration model easier to work with or building an entire UI for it, I finally realized it would be way easier to just do it as code, and there was no better choice than Lua.

Add a few helper functions, and the configuration that dynamically changes the target temps throughout the day is a 12 line Lua function that determines what the HVAC system should do based on the current state, current time, and the current temperature.

The biggest criticism I've heard is "I don't want my config language to be Turing-complete."

I agree; nobody does. But two of the three config languages I used started out as static no-frills languages and eventually became Turing-complete by accretion of need to support more and more complicated configurations, and given that they were headed there eventually, I wish they'd been Lua instead of a Turing-complete bespoke language with its own parser, its own (bad) error messages, little thought paid to debugging ("hey, it was never supposed to be complicated enough to need debugging!"), and no tooling.

That’s exactly where Lua came from. They had a comfort language that was heading towards Turing complete. So, they took it there intentionally rather than accidentally.

I wonder why the author doesn't use Teal [0] - a typed dialect of lua.

[O] https://github.com/teal-language/tl

From the post: "I’m aware of typed languages that compile to Lua, but here’s a native approach."

Regarding teal specifically: It currently doesn't support union types as described in the post (see the 'Current limitations of union types' section of the tutorial: https://pdesaulniers.github.io/tl/tutorial.html

Lack of tooling/LSP support compared to Lua. A rather popular neovim plugin, gitsigns, recently switched from teal to regular lua because, at least in part, the type annotations available via lua-language-server.

https://github.com/lewis6991/gitsigns.nvim/commit/4d63d996b0...

Reply on news.ycombinator.com