"Transpiler" is a common term for source-to-source compilers in the industry, but compiler is the more general term (i.e. a transpiler is a kind of compiler). In academia, the term "transpiler" is somewhat sneered at. A source-to-source compiler is still a compiler, because conceptually compiling into assembly is also technically source-to-source.
> How confident are you in the soundness of the type system?
I am confident it is not sound! That is by design. A typical example is how function arguments are bivariant, to allow for callbacks expressed the way programmers usually expect them to work (TypeScript does something similar).
> Also, are there any Lua constructs that are difficult/impossible to type?
Yes, many of them. The type system and the compiler are pragmatically very simple -- there are many design decisions made to favor simplicity of specification and/or implementation. (Compare the single-file, single-pass Teal compiler done mostly by a single person with the amount of engineering resources that Microsoft has put into TypeScript.) For a concrete example, we have special-cased polymorphism for functions, intended to use with very dynamically-typed Lua functions from the broader Lua ecosystem, but you cannot express similar polymorphism in Teal itself.
> Is type checking decidable? (Is the type system Turing complete?)
There is a proof (which I can't find right now) that type checking is not decidable once you combine parametric polymorphism (generics) and intersection types (like the poly functions I mentioned above), but the forms of these features supported by Teal have some restrictions which make me not extend such claims directly. And of course, I can't even claim that the implementation of the theoretical model is bug-free. The model is evolving, the implementation always lags a bit behind.
In any case, the goal for Teal's type system is not academic purity, but pragmatic utility. Other comments in this thread alluded to this as well -- there are practical constraints that come from targeting an existing language and ecosystem. Of course, there are many ways one can approach such challanges. Teal is one of them and there were and are certainly others! Everyone is free to take their shot at where they want to be in the Unix-Philosophy/Worse-is-Better vs. Lisp-Philosophy/The-Right-Thing design gradient.
Thanks for the detailed answer! I just wish the website was more upfront about this. I cannot find anything about "soundness" on the front page or in the docs.
I think you could basically copy your comment into an FAQ section or something on the front page.
In our experience, single-element tuples are just never used in practice. There has been some discussion on how to add syntax for them, but I think it's more of a desire for orthogonality than for a practical need.
Teal's output is currently pretty much 1-to-1 with the input apart from removing all of the type information of course. (I've been trying hard to keep it that way so that the error messages in stack traces match the input lines without having to do source mapping.)
Teal creator here! Thank you for the kind words, super happy to see people being productive with it!!
On your wishlist items:
1. There are a few third-party projects that bundle Lua code. One that comes to mind is https://lrocket.codeberg.page/ — I don't know if this functionality should be brought into Teal itself, it sounds to me like something better left to the surrounding tooling?
2. Unfortunately those annoyances are part of the heterogeinity of the Lua ecosystem, but Teal tries to paper over them using the compat53 library (which, granted, is not available everywhere if you want to do a pure-Lua deployment on existing Lua environments). The --gen-target and --gen-compat flags should still help some, hopefully!
3. Not sure what you mean there -- you mean adding chunks of untyped Lua _in the same file_? I think that if you have a json.lua and a json.d.tl file, then it should use the definition file only and leave the .lua file alone. At least that's the intended behavior!
4. That's up to GitHub :) Last time I checked their docs I think they want something like 100 or 200 projects using the language for considering adding native highlighting for it on the website. But you can add a .gitattributes file to the root of your repository like this https://github.com/teal-language/tl/blob/master/.gitattribut... and at least it will display .tl files with .lua highlighting.
1. Yeah, there are third party bundlers, but none of em worked too well for me. You are right: it should be separate
2. If I recall correctly, gen-target didn't hit it because I was using some very esoteric bullshit from the luajit internal spec that couldn't have nice typing
3. Yes, untyped lua in the same file. The problem is that I want everything in a single file for distribution and embedding - kind of like the SQLite amalgamation. It'd be super cool to just add in my dnadesign.lua or dnadesign.tl file and have full bioinformatics in almost any language! Definition files don't work as well there - I still kind of use them for the type definitions, but then embed the raw file as a string
4. YES THANK YOU! I'm not sure if it is in the docs but this is SO useful!
Teal currenly supports generating code for Lua 5.1 and up, including LuaJIT. There are compiler flags --gen-target and --gen-compat which control various specifics of code generation.
There is also the compat53 library which polyfills most of the missing parts. The Teal compiler has --gen-target and --gen-compat flags which adapts the generated Lua code for different Lua versions, and allows using the compat53 library behind the scenes if desired, so you can get a mostly Lua-5.3+ experience over LuaJIT using Teal.
I wonder if it would be possible to make a usable dedicated hardware encryption card for the Apple II using 80s tech.
(Of course, it has the downside that upgrading to a new protocol would require a new card, but hey... we're just having fun musing on retro-futurism here!)
