I made a tiny library for switches and sum types in Lua
1–8 of 8 posts
Re: I made a tiny library for switches and sum types in Lua
#2Cool.
I admit it takes a minute to grok, and the example of a_square being a rectangle but not a square added some unnecessary confusion.
Re: I made a tiny library for switches and sum types in Lua
#3Cool. I admit it takes a minute to grok, and the example of a_square being a rectangle but not a square added some unnecessary confusion.
Thanks, fixed.
Re: I made a tiny library for switches and sum types in Lua
#4Sorry but this is 12 lines of Lua code, what is the value proposition/use case here? I'm legitimately curious.
Re: I made a tiny library for switches and sum types in Lua
#5Sorry but this is 12 lines of Lua code, what is the value proposition/use case here? I'm legitimately curious.
Honestly, not much.
I found it nice how it's possible to emulate switches in Lua with so little code, without the result looking too ugly. You may find this pattern useful. That's it.
The catch is that, unlike with normal switches or with a series of "if"s, there's a whole bunch of indirection added via functions, so it's not very efficient.
Perhaps LuaJIT can inline these functions, but I haven't tested it.
Re: I made a tiny library for switches and sum types in Lua
#6Pretty neat - I might incorporate this into my awesomeWM, which has a lot of if/else provisioning for some custom window functions I wrote
Re: I made a tiny library for switches and sum types in Lua
#7Lua is very flexible and very fun to hack! With a different approach [0], you can get a switch on tag that feels more like a "standard" switch statement, eg.:
result = switch(shape) {
rectangle = function(r)
return "a rectangle with width " .. r.width
end,
function(s)
return "an unknown shape"
end
}
[0]: https://gist.github.com/krajzeg/9bd8806fb72c1ae22eb931b42b3d...
Re: I made a tiny library for switches and sum types in Lua
#8Lua is very flexible and very fun to hack! With a different approach [0], you can get a switch on tag that feels more like a "standard" switch statement, eg.: result = switch(shape) { rectangle = function(r) return "a rectangle with width " .. r.width end, function(s) return "an unknown shape" end } Can't easily get rid of the pesky functions, though. [0]: https://gist.github.com/krajzeg/9bd8806fb72c1ae22eb931b42b3d.…
I like your approach.
(Implicitly) using [1] instead of [false] as a default is less typing for sure (but maybe a bit more confusing?).
Also, objects being switched on really have to be tables in my version anyway (since overriding __call for builtin types seems harsh to me), so having a tag field right in them as opposed to creating a metatable should be more efficient.
For my version I'll add a value-weak map of metatables to dedup them, should work as well.
In terms of functions, yeah, I don't think you can get rid of them, but (in the example) you can avoid (r) and (s) params if you assume that the functions lexically close over shape.