7 ms·

> Teal is a statically-typed dialect of Lua. I was expecting Teal to be "Lua + type annotations", similar to Mypy. However from a quick look it does indeed see

by pansa2 1y ago

> Teal is a statically-typed dialect of Lua. I was expecting Teal to be "Lua + type annotations", similar to Mypy. However from a quick look it does indeed seem to be a "dialect" in its own right. Teal is Lua-like and compiles to Lua, but there's more to it than just static types. Perhaps it's more similar to TypeScript? For example, Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces. It changes the variable scoping rules and even adds macro expressions. Teal therefore seems substantially more complex than Lua. The author recognizes this in the conclusion to a recent presentation [0]: Lua is "small and simple", maybe Teal is "something else"? Lua is for "scripting", maybe Teal is better suited to "applications/libraries"? [0] https://youtu.be/Uq_8bckDxaU?t=1618 https://youtu.be/Uq_8bckDxaU?t=1618

Benjamin_Dobell 1y ago
You can get pretty far by bolting annotations onto Lua (no compilation step), for example using my IDE: https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis Admittedly, I've been focused on some other things recently, but still with some focus on type safety e.g. https://breaka.club/blog/godots-most-powerful-scripting-language https://breaka.club/blog/godots-most-powerful-scripting-lang...
lifthrasiir 1y ago
That was a major concern when I was using Lua at work. Pretty much every type checker in Lua required transpiling, which doesn't work for many environments (e.g. Redis script). My Kailua [1] was designed that in mind but didn't reach its full potential. [1] https://github.com/devcat-studio/kailua/ https://github.com/devcat-studio/kailua/
wyldfire 1y ago
> Perhaps it's more similar to TypeScript? Funny you should mention that: > It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.
90s_dev 1y ago
> Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces They're all just Lua tables with specialized type checking for specific behavior. I really wish the Lua authors would add official types to Lua. The time has come.
- pansa2 1y ago
  > 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 to change radically - adding a type checker would invalidate the current approach of using a single-pass source-to-bytecode compiler.
  - dottrap 1y ago
    >> 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. You both are kind of right. The Lua authors have been working on the new companion language to Lua named Pallene. Pallene is a subset of Lua that adds types, not for the sake of types themselves, but for the purpose of performance. The Pallene compiler can generate optimized native code that potentially removes the need to manually write a module for Lua in C. The other cool trick is that Pallene and Lua are completely interoperable with each other, so Pallene can be added to existing Lua projects, and you can opt to use regular Lua for the dynamic parts of your code where compilers won't be able to optimize much and strong types might be more trouble than help. Here is a talk Roberto Ierusalimschy gave about Pallene. https://www.youtube.com/watch?v=pGF2UFG7n6Y https://www.youtube.com/watch?v=pGF2UFG7n6Y
    - 90s_dev 1y ago
      Docs https://github.com/pallene-lang/pallene/blob/master/doc/manual.md https://github.com/pallene-lang/pallene/blob/master/doc/manu... Looks similar to Teal. This is relatively exciting. Also, called it! Disappointed that it maintains syntactic Lua compatibility. Would have been a good time for a clean slate on the shoulders of hindsight.
SoylentOrange 1y ago
Just a small note about mypy and python - annotations are first-class citizens in Python3 and are not tied to any particular type checking system such as mypy, but are instead a core part of the language and actually serve vital functions in frameworks and libraries that are used to check interfaces such as Pydantic and FastAPI (eg URL params). Mypy is just one type checker for Python, but there are many others including pyright. In fact pyright is quickly becoming the dominant checker over mypy.
- pansa2 1y ago
  Am I right in thinking that Python's type annotation syntax originally came from Mypy though? IIRC Mypy started off as a type annotation syntax and corresponding type checker for Python. Mypy's type annotations were adopted by Python itself (in version 3.5 - PEP 484), which reduced Mypy's role to be just a type checker. Since then, type annotations have indeed become a core part of Python - not only are they used in frameworks and libraries, but are also required to use language features like @dataclass.
  - thristian 1y ago
    No, Python's current type annotation syntax was added in Python 3.0 as a generic annotation syntax, in the hope that somebody else might come along and build a type-checker or other tooling on top: https://peps.python.org/pep-3107/ https://peps.python.org/pep-3107/ MyPy was one such tool, and I think it had conventions for adding type annotations in comments, in places where Python didn't yet support them (such as variable assignment), but I'm pretty sure it was never a TypeScript-style pre-processor - type-annotated programs always ran directly in the unmodified CPython interpreter.
creatonez 1y ago
It's interesting that you mention Typescript. In Typescript's early history, they added a bunch of features that they either thought would make it nicer for C# devs (classes, enums, option chaining, decorators, namespaces, etc.). Eventually, a bunch of these features were added to Javascript natively in nearly the exact same way they were implemented in Typescript. Now, the only remaining non-type-related features not added to Javascript are enums and namespaces, which will never be added because they're poorly designed. Even the Typescript type syntax (but with ignored semantics) may get added to Javascript under a WIP proposal. Some of these features were perhaps mistakes -- private in TS and private in JS will never be able to mean the same thing, and `class` syntax is iffy -- but overall there was an improvement. By ambitiously adding useful features, could Teal push the upstream to make progress? Probably not because Lua's scope is intended to be small (and we're no longer in the same context as 2015 era Typescript and tc39), but it's interesting to think about.
- VoidWhisperer 1y ago
  Enums are possibly going to end up in JS eventually - this proposal[0] is at stage 1 (i know the readme says stage 0, it looks like there is a PR to update this). Granted, that means 'under consideration' but it is a start [0]: https://github.com/tc39/proposal-enum https://github.com/tc39/proposal-enum
- koito17 1y ago
  Minor nitpick: decorators are still in "stage 3". Not formally part of ECMAScript standard yet.[1] Anyway, that has not stopped large parts of the JavaScript ecosystem -- notably Angular -- from using an experimental variant of decorators, such as the one provided by TypeScript. [2] [1] https://github.com/tc39/proposal-decorators https://github.com/tc39/proposal-decorators [2] https://github.com/angular/angular/issues/48096 https://github.com/angular/angular/issues/48096
  - chamomeal 1y ago
    I feel conflicted about decorators, which I’ve only used in the context of nestjs. They’re undeniably productive, but they’re very black box-ish. Just slap a decorator on a method, now it’s a cron job! Slap a decorator on, and now you’re logging the function call! I feel like a lot of problems that decorators solve could also be solved with good ol’ higher order functions. Decorators also give zero (or limited? Idk) information to the typescript compiler, so you end up asserting a lot of types instead of inferring them. I have all these gripes, but it really is amazing to throw decorators on stuff and have it work. Especially with third party libraries that provide decorators. I gave a nestjs app a queueing system by installing bullmq, then just slapping the bullmq decorators around! Makes me think of the Rich Hickey “simple made easy” talk. Decorators are definitely not simple, which makes me naturally dislike them. But damn are they easy!!
ufo 1y ago
I'm not sure if I follow. Teal still compiles all those things into plain Lua tables, it's just that the type system has different table subtypes for better type checking. I think the variable scoping is also the same as regular Lua?
TulliusCicero 1y ago
> Perhaps it's more similar to TypeScript? I mean that's exactly what the page says, doesn't it? > It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.

by pansa2 1y ago

Benjamin_Dobell 1y ago

You can get pretty far by bolting annotations onto Lua (no compilation step), for example using my IDE: https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis Admittedly, I've been focused on some other things recently, but still with some focus on type safety e.g. https://breaka.club/blog/godots-most-powerful-scripting-language https://breaka.club/blog/godots-most-powerful-scripting-lang...

lifthrasiir 1y ago

That was a major concern when I was using Lua at work. Pretty much every type checker in Lua required transpiling, which doesn't work for many environments (e.g. Redis script). My Kailua [1] was designed that in mind but didn't reach its full potential. [1] https://github.com/devcat-studio/kailua/ https://github.com/devcat-studio/kailua/

wyldfire 1y ago

> Perhaps it's more similar to TypeScript? Funny you should mention that: > It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.

90s_dev 1y ago

> Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces They're all just Lua tables with specialized type checking for specific behavior. I really wish the Lua authors would add official types to Lua. The time has come.

pansa2 1y ago
> 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 to change radically - adding a type checker would invalidate the current approach of using a single-pass source-to-bytecode compiler.
- dottrap 1y ago
  >> 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. You both are kind of right. The Lua authors have been working on the new companion language to Lua named Pallene. Pallene is a subset of Lua that adds types, not for the sake of types themselves, but for the purpose of performance. The Pallene compiler can generate optimized native code that potentially removes the need to manually write a module for Lua in C. The other cool trick is that Pallene and Lua are completely interoperable with each other, so Pallene can be added to existing Lua projects, and you can opt to use regular Lua for the dynamic parts of your code where compilers won't be able to optimize much and strong types might be more trouble than help. Here is a talk Roberto Ierusalimschy gave about Pallene. https://www.youtube.com/watch?v=pGF2UFG7n6Y https://www.youtube.com/watch?v=pGF2UFG7n6Y
  - 90s_dev 1y ago
    Docs https://github.com/pallene-lang/pallene/blob/master/doc/manual.md https://github.com/pallene-lang/pallene/blob/master/doc/manu... Looks similar to Teal. This is relatively exciting. Also, called it! Disappointed that it maintains syntactic Lua compatibility. Would have been a good time for a clean slate on the shoulders of hindsight.

SoylentOrange 1y ago

Just a small note about mypy and python - annotations are first-class citizens in Python3 and are not tied to any particular type checking system such as mypy, but are instead a core part of the language and actually serve vital functions in frameworks and libraries that are used to check interfaces such as Pydantic and FastAPI (eg URL params). Mypy is just one type checker for Python, but there are many others including pyright. In fact pyright is quickly becoming the dominant checker over mypy.

pansa2 1y ago
Am I right in thinking that Python's type annotation syntax originally came from Mypy though? IIRC Mypy started off as a type annotation syntax and corresponding type checker for Python. Mypy's type annotations were adopted by Python itself (in version 3.5 - PEP 484), which reduced Mypy's role to be just a type checker. Since then, type annotations have indeed become a core part of Python - not only are they used in frameworks and libraries, but are also required to use language features like @dataclass.
- thristian 1y ago
  No, Python's current type annotation syntax was added in Python 3.0 as a generic annotation syntax, in the hope that somebody else might come along and build a type-checker or other tooling on top: https://peps.python.org/pep-3107/ https://peps.python.org/pep-3107/ MyPy was one such tool, and I think it had conventions for adding type annotations in comments, in places where Python didn't yet support them (such as variable assignment), but I'm pretty sure it was never a TypeScript-style pre-processor - type-annotated programs always ran directly in the unmodified CPython interpreter.

creatonez 1y ago

It's interesting that you mention Typescript. In Typescript's early history, they added a bunch of features that they either thought would make it nicer for C# devs (classes, enums, option chaining, decorators, namespaces, etc.). Eventually, a bunch of these features were added to Javascript natively in nearly the exact same way they were implemented in Typescript. Now, the only remaining non-type-related features not added to Javascript are enums and namespaces, which will never be added because they're poorly designed. Even the Typescript type syntax (but with ignored semantics) may get added to Javascript under a WIP proposal. Some of these features were perhaps mistakes -- private in TS and private in JS will never be able to mean the same thing, and `class` syntax is iffy -- but overall there was an improvement. By ambitiously adding useful features, could Teal push the upstream to make progress? Probably not because Lua's scope is intended to be small (and we're no longer in the same context as 2015 era Typescript and tc39), but it's interesting to think about.

VoidWhisperer 1y ago
Enums are possibly going to end up in JS eventually - this proposal[0] is at stage 1 (i know the readme says stage 0, it looks like there is a PR to update this). Granted, that means 'under consideration' but it is a start [0]: https://github.com/tc39/proposal-enum https://github.com/tc39/proposal-enum
koito17 1y ago
Minor nitpick: decorators are still in "stage 3". Not formally part of ECMAScript standard yet.[1] Anyway, that has not stopped large parts of the JavaScript ecosystem -- notably Angular -- from using an experimental variant of decorators, such as the one provided by TypeScript. [2] [1] https://github.com/tc39/proposal-decorators https://github.com/tc39/proposal-decorators [2] https://github.com/angular/angular/issues/48096 https://github.com/angular/angular/issues/48096
- chamomeal 1y ago
  I feel conflicted about decorators, which I’ve only used in the context of nestjs. They’re undeniably productive, but they’re very black box-ish. Just slap a decorator on a method, now it’s a cron job! Slap a decorator on, and now you’re logging the function call! I feel like a lot of problems that decorators solve could also be solved with good ol’ higher order functions. Decorators also give zero (or limited? Idk) information to the typescript compiler, so you end up asserting a lot of types instead of inferring them. I have all these gripes, but it really is amazing to throw decorators on stuff and have it work. Especially with third party libraries that provide decorators. I gave a nestjs app a queueing system by installing bullmq, then just slapping the bullmq decorators around! Makes me think of the Rich Hickey “simple made easy” talk. Decorators are definitely not simple, which makes me naturally dislike them. But damn are they easy!!

ufo 1y ago

I'm not sure if I follow. Teal still compiles all those things into plain Lua tables, it's just that the type system has different table subtypes for better type checking. I think the variable scoping is also the same as regular Lua?

TulliusCicero 1y ago

> Perhaps it's more similar to TypeScript? I mean that's exactly what the page says, doesn't it? > It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.