Live data from Hacker News

Teal – A statically-typed dialect of Lua

teal-language.org

81–90 of 176 posts

Re: Teal – A statically-typed dialect of Lua

#81

Earlier quoted context omitted.

People get this way about TypeScript too, and it always perplexes me. These projects are about adding types to untyped languages, and that comes with a few givens: * Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll. * There will always be constructs that you can't type. See above. * If your type system is going to usefully type enough of the…

> Your type system cannot be sound. This one I disagree with. Type assertions with runtime checks could keep the typed fragments sound, unlike TypeScript and Python. Also see Elixir's strong arrow proposal for how to encode which assertions can be elided on function calls (because the function will assert them already).

TypeScript supports runtime type assertions, but it doesn't mandate them or write them for you.

I should have said your type system cannot be sound without runtime overhead. And I don't believe that choosing automatic runtime overhead is the right move.

Re: Teal – A statically-typed dialect of Lua

#82
post #3

I'm so relieved to see more types being added to good languages. So Teal is to Lua as TypeScript is to JavaScript. Which means it automatically plays well with any Lua environment. Unlike luau and nelua which are also statically typed but have their own runtimes. What version of Lua does it use? Lua gets new versions every few years so I don't know why so many impls don't continuously upgrade to the latest version.

Teal compiles to Lua text files. I believe it's compatible with both Lua 5.1 and 5.4

Re: Teal – A statically-typed dialect of Lua

#83
post #56

Earlier quoted context omitted.

Each new Lua version has breaking changes that are of dubious value to keep on the upgrade treadmill. Something like a Python2->3. LuaJIT is famously on 5.1 with no signs of moving.

Not moving straight to a more recent version, but still cherry-picking some parts of them. You can see some functionalities from Lua 5.2 and 5.3 are working in Luajit: https://luajit.org/extensions.html

I guess all of this means Lua has "flavors" more than "versions".

Re: Teal – A statically-typed dialect of Lua

#84

Earlier quoted context omitted.

People get this way about TypeScript too, and it always perplexes me. These projects are about adding types to untyped languages, and that comes with a few givens: * Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll. * There will always be constructs that you can't type. See above. * If your type system is going to usefully type enough of the…

> Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll. I think you could prove that you can't construct a sound & complete type system for Lua. But just saying "Your type system cannot be sound" by itself is definitely wrong. I don't understand why people are throwing out both soundness & completeness, instead of at least retaining one (and I th…

Why, though? Completeness matters more than soundness in practice for this kind of language, which is a large part of what gave TypeScript its edge. The only people who complain about soundness seem to be those whose approach to TypeScript is one of theoretical interests rather than practical application.

Re: Teal – A statically-typed dialect of Lua

#85

I've been diving into Lua (a little late to this party, but turns out it's a perfect language to rewrite some commandline scripts I had that were getting unwieldy in Bash, especially with LLM assistance!) and it's really something of an eye-opener. LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm , typically. Lua is embedded in a surprisingly massive numbe…

> LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically

Cannot confirm this. It might be true on selected micro benchmarks. Here are the results of the Are-we-fast-yet benchmark suite, which includes a decent set of benchmarks challenging CPU, cache and memory access: https://github.com/rochus-keller/Oberon/blob/master/testcase....

On average, the C and C++ implementations are five times faster than LuaJIT.

> There are also some neat languages that compile to (transpile to?) Lua

Here is a comprehensive list: https://github.com/hengestone/lua-languages. Lanuages like Oberon or Luon directly compile to LuaJIT bytecode (i.e. not to Lua).

Re: Teal – A statically-typed dialect of Lua

#86

Earlier quoted context omitted.

People get this way about TypeScript too, and it always perplexes me. These projects are about adding types to untyped languages, and that comes with a few givens: * Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll. * There will always be constructs that you can't type. See above. * If your type system is going to usefully type enough of the…

> Your type system cannot be sound. This one I disagree with. Type assertions with runtime checks could keep the typed fragments sound, unlike TypeScript and Python. Also see Elixir's strong arrow proposal for how to encode which assertions can be elided on function calls (because the function will assert them already).

A tricky tradeoff is that, because Teal compiles to Lua source, adding those run-time type checks would incur some considerable overhead. I've seen other languages in this space easily run 2 or 3 times slower when run-time checks are turned on. It's an open research problem.

You might be interested in checking out Pallene. Like Teal it's also Lua with types but it does check types at run-time, in an efficient way. However, Pallene's type system is currently not as featureful and production ready as Teal.

Re: Teal – A statically-typed dialect of Lua

#88

Earlier quoted context omitted.

> Your type system cannot be sound. This one I disagree with. Type assertions with runtime checks could keep the typed fragments sound, unlike TypeScript and Python. Also see Elixir's strong arrow proposal for how to encode which assertions can be elided on function calls (because the function will assert them already).

TypeScript supports runtime type assertions, but it doesn't mandate them or write them for you. I should have said your type system cannot be sound without runtime overhead. And I don't believe that choosing automatic runtime overhead is the right move.

The problem is not that it doesn't write them for you, but that `as MyType` is way too ergonomic of a syntax for unchecked assertions, whereas checked assertions require effectively parsing the structure manually with typeof checks.

TypeScript desperately needs a way to derive type-guarding functions from types (and so does every gradually-typed language). There're libraries for this but you need to define the types themselves through combinators.

Re: Teal – A statically-typed dialect of Lua

#89
post #10

Earlier quoted context omitted.

Seconded.

I think you and GP both mean that this TEAL is adjacent to crptocurrency, and therefore, who cares about stepping on toes? This heuristic works well in most cases maybe, but will lead to false positives sometimes. May I gently suggest that this might be one of those cases. Algorand is the project of this fellow https://en.m.wikipedia.org/wiki/Silvio_Micali Credentials aren't faultless but they do provide a certain we…

I meant that I have a sort of affection for Lua, so it gets preferential treatment in my book, and therefore Teal ought to get the name above another relatively random project with the same name.

Re: Teal – A statically-typed dialect of Lua

#90
post #40

Earlier quoted context omitted.

> I really wish the Lua authors would add official types to Lua. Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python. As Teal shows, it would require giving up one of Lua's core features: tables as the language's single data structure. It would significantly complicate a language known for its simplicity. Even the implementation would need…

> As Teal shows, [official typed Lua] would require giving up one of Lua's core features: tables as the language's single data structure. Is that true ... you can't have typed tables without giving up tables as a data structure?

You can't have typed tables without giving up tables as the language's single data structure. You would have tables and typed tables which are essentially just arrays with extra steps.
Post reply on HN