3 ms·

> Every type in Teal accepts nil as a valid value, even if, like in Lua, attempting to use it with some operations would cause a runtime error, so be aware! Th

> Every type in Teal accepts nil as a valid value, even if, like in Lua, attempting to use it with some operations would cause a runtime error, so be aware! There has been a fair bit of discussion about this design decision/limitation recently in other channels. Seems like that's one of the main safety checks you'd want/expect from a compiler. That said - Pallene[1] and Nelua[2] are two very promising projects in similar spaces (although both are offering more than Teal's scope) [1]: https://github.com/pallene-lang/pallene https://github.com/pallene-lang/pallene [2]: https://github.com/edubart/nelua-lang https://github.com/edubart/nelua-lang

veltas 6y ago
In my opinion, this is a valid alternative and not a straight deficit. Lua demands using a lot of maybe-nil values, and 90% of the usefulness of types still applies if you 'hide' this. And there is a productivity gain from not having to consider nils in your types, because handling often requires code, annotation, or thought. But there is a loss of productivity to fixing nil errors that aren't caught by other typing features. Places where the typing in Teal is still helpful: accessing the wrong thing, typos of variable names, wrong number or type of arguments to functions. That covers most of the statically-detectable errors.
hugomg 6y ago
Pallene and Teal are in a bit of a different space. Teal is focused on compile-time type checking. The intention is to encourage you to add type annotations to your entire Lua codebase. It's another take at the problem that Typed Lua was trying to solve. A Typed Lua 2.0, if you want to call it that way. Pallene, on the other hand, is more focused on performance. The tradeoff is that it doesn't cover the entirety of the Lua language, just the features that we can generate fast code for. The intention is that you can write the performance-critical parts in Pallene and glue everything together using Lua (or Teal). That said, I certainly wouldn't be surprised if we saw more cross pollination of ideas between these two languages in the future :)
- hisham_hm 6y ago
  > The intention is to encourage you to add type annotations to your entire Lua codebase. We definitely like to encourage the use of types (we <3 types!), but, just to clarify, Teal does support hybrid Lua/Teal codebases well, by use of definition files a la TypeScript. The Teal compiler itself is currently a "main program" written in Lua and the "core compiler" written in Teal. :) > A Typed Lua 2.0, if you want to call it that way. please don't, people are already confused as is. :) (For those not well-versed in Lua history like Hugo and me :), "Typed Lua" was an earlier academic project, which had different design criteria such as being able to type check unannotated "idiomatic" Lua, which made it a much more interesting research project and a much more difficult industrial one — Teal is very pragmatic, with the intention of being immediately usable but no intention of being academically interesting, more in the TypeScript mindset. This talk goes through the history, for those interested: https://www.youtube.com/watch?v=VUThGgxOf28 https://www.youtube.com/watch?v=VUThGgxOf28 ) > That said, I certainly wouldn't be surprised if we saw more cross pollination of ideas between these two languages in the future :) For sure! There are some exciting possibilities there!

veltas 6y ago

In my opinion, this is a valid alternative and not a straight deficit. Lua demands using a lot of maybe-nil values, and 90% of the usefulness of types still applies if you 'hide' this. And there is a productivity gain from not having to consider nils in your types, because handling often requires code, annotation, or thought. But there is a loss of productivity to fixing nil errors that aren't caught by other typing features. Places where the typing in Teal is still helpful: accessing the wrong thing, typos of variable names, wrong number or type of arguments to functions. That covers most of the statically-detectable errors.

hugomg 6y ago

Pallene and Teal are in a bit of a different space. Teal is focused on compile-time type checking. The intention is to encourage you to add type annotations to your entire Lua codebase. It's another take at the problem that Typed Lua was trying to solve. A Typed Lua 2.0, if you want to call it that way. Pallene, on the other hand, is more focused on performance. The tradeoff is that it doesn't cover the entirety of the Lua language, just the features that we can generate fast code for. The intention is that you can write the performance-critical parts in Pallene and glue everything together using Lua (or Teal). That said, I certainly wouldn't be surprised if we saw more cross pollination of ideas between these two languages in the future :)

hisham_hm 6y ago
> The intention is to encourage you to add type annotations to your entire Lua codebase. We definitely like to encourage the use of types (we <3 types!), but, just to clarify, Teal does support hybrid Lua/Teal codebases well, by use of definition files a la TypeScript. The Teal compiler itself is currently a "main program" written in Lua and the "core compiler" written in Teal. :) > A Typed Lua 2.0, if you want to call it that way. please don't, people are already confused as is. :) (For those not well-versed in Lua history like Hugo and me :), "Typed Lua" was an earlier academic project, which had different design criteria such as being able to type check unannotated "idiomatic" Lua, which made it a much more interesting research project and a much more difficult industrial one — Teal is very pragmatic, with the intention of being immediately usable but no intention of being academically interesting, more in the TypeScript mindset. This talk goes through the history, for those interested: https://www.youtube.com/watch?v=VUThGgxOf28 https://www.youtube.com/watch?v=VUThGgxOf28 ) > That said, I certainly wouldn't be surprised if we saw more cross pollination of ideas between these two languages in the future :) For sure! There are some exciting possibilities there!