Is it implemented as a compiler, tl, which compiles .tl source code into .lua files? Who knows
Teal – A statically-typed dialect of Lua
151–160 of 176 posts
Re: Teal – A statically-typed dialect of Lua
#152After having embedded Lua in my game engine and having worked with some Lua games I've come to conclusion that: - Lua is great from the integrator/engine dev perspective. It's easy to embed and there are several libraries that help with creating bindings between Lua and your game classes. - Lua has absolutely terrible runtime performance especially when the GC stalls. You soon learn that you have to start moving code…
Re: Teal – A statically-typed dialect of Lua
#153Earlier quoted context omitted.
Alas, as of last month we changed Pallene's compiler and it now generates C gotos for control flow. ( ^ _ ^ メ ) It helped with certain optimizations...
Ha! Called it again! But why gotos instead of proper control flow? Is it just easier to emit?
Re: Teal – A statically-typed dialect of Lua
#154Years ago, I tried lua and wasn't impressed. Then I started using Neovim, did the necessary configuration in lua, but continued writing my own scripts in vimscript. Later I started using wezterm and decided to give lua a second shot, and I began to really like it. I realized my initial dislike for lua stemmed from my experience with javascript (back in the jwquery days), where maintaining large codebases felt like na…
> That being said, lua's lack of popularity probably stems from its limited stdlib, which often feels incomplete, and the absence of a robust package manager. luarocks is a pain to work with. And indexing arrays starting from 1 rather than 0.
Re: Teal – A statically-typed dialect of Lua
#155Earlier quoted context omitted.
Sure, if you compare via semantics Lua and Javascript make sense to liken. But in terms of complexity, Lua is far more like C. There's no unfucking all the horrible decisions baked into javascript and I wouldn't touch it with a ninety-foot pole, but Lua still has some hope.
To be fair Lua also made some bad decisions, though maybe not as bad as javascript: - tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0 - indexes start at 1 - assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad…
Re: Teal – A statically-typed dialect of Lua
#156Years ago, I tried lua and wasn't impressed. Then I started using Neovim, did the necessary configuration in lua, but continued writing my own scripts in vimscript. Later I started using wezterm and decided to give lua a second shot, and I began to really like it. I realized my initial dislike for lua stemmed from my experience with javascript (back in the jwquery days), where maintaining large codebases felt like na…
BTW, you might want to check Lux [1], it's a new approach for Lua packaging. They launched it recently, so there's a lot of work going on. But it looks and feels very promising [1]: https://github.com/nvim-neorocks/lux
Re: Teal – A statically-typed dialect of Lua
#157Oof. What is it about the devs who prefer static typing that they insist on bolting it onto every scripting language they can? It's nearly a compulsive disorder. There's plenty of languages with compile time type safety, just go use one of them and leave the perfectly good dynamic ones alone. Static typing proponents need accept that dynamic typing is a perfectly valid way to write and run code: It's way less verbose…
Because when your project reaches the 10k lines mark, you want something telling you "Woops, that function you declared only accepts numbers as the first parameter" and there's nothing preventing lua to have minimal compile time safety while also being backward compatible in fact, I think one of the lua transpilers allowed for function (n number, s string, a) (a is any type here)
Oof. The same old excuse. So you prematurely optimize your code based on a theoretical line count in the future, cluttering your code with redundant information to save yourself from that one bug you'll encounter in QA anyways. Got it. Makes total sense. I bet you like Java FactoryFactoryImpls as well.
If you already know your code will reach 10 kloc in a project where catching a type related bug is that important, choose an appropriate type safe language. So many wasted man hours dealing with truly pedantic details.
Re: Teal – A statically-typed dialect of Lua
#158Earlier quoted context omitted.
Any recommendations going from bash to lua to watch out for except indexing?
I haven’t found many downsides yet. I was already starting to rewrite some things in Awk (which I was drawn to for similar reasons- fast script startup time, simple easy language with good defaults), but Awk (while still also awesome) isn’t really designed for stuff beyond a certain size (no signal handling unless you use a fork, for example) LuaJIT is missing bignums, ints that aren’t floats, bit operations, and nat…
https://web.tecgraf.puc-rio.br/~lhf/ftp/lua/#limath
luajit does have integers (try 5ull+6), bit operations via the bit library (absorbed from lua5.2)
Re: Teal – A statically-typed dialect of Lua
#159Earlier quoted context omitted.
Lua is a good language. It's like C, if C were a scripting language. It's got an awesome C API. It's fast, lightweight, and embeddable. It's more performant than Python. It's a staple in video game scripting.
It's nothing like C, and that's so much of its charm. Semantically, Lua is almost identical to the core of JavaScript. Metatables are a genius alternative to prototype chains. Lua's syntax is beautifully simple and unambiguous, but at the cost of being moderately inconvenient in 2025 unfortunately. It could benefit from an ESNext-style renewal. I get why they made the C API that way, but in practice it's very easy to…
local print = print
("hello"):format()
local foo = func
("args to func"):itreturnedatable("!")Re: Teal – A statically-typed dialect of Lua
#160Earlier quoted context omitted.
Ha! Called it again! But why gotos instead of proper control flow? Is it just easier to emit?
We switched from a hierarchical internal representation to a flat one, with gotos. Made it easier to write textbook otimization algorithms. In theory we could try to reconstruct the if and while statements when it's time to emit C, but gotos are more straightforward now.