886 karma · joined April 2, 2011
> 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.
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.
Again, thank you so much for the feedback!
(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!)
That does not invalidate the point that cars _are_ highly pollutant and shouldn't be the primary means of transportation in any sustainable society.
[1] https://news.ycombinator.com/item?id=26319996 [2] https://news.ycombinator.com/item?id=26319974 [3] https://news.ycombinator.com/item?id=26319558
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 )
> 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!
Yeah, Teal was motivated by my experiences developing LuaRocks, the Lua package manager, which is also a significant pure-Lua application, as well as other experiences working with large Lua codebases.
We've been making some good progress on the compiler and the overall tooling (VS Code and Vim plugins, soon general LSP), and I can say that the overall development experience in Teal already feels smoother than pure Lua thanks to the compiler assistance.
My intention with Teal is to be able to support use-cases such as yours, Love2D, and so on. In my FOSDEM talk earlier this month ( https://www.youtube.com/watch?v=OqXbnaDR8QY ) I mentioned some of the challenges involved in supporting more existing Lua codebases, and how I think we'll need to add a bit of a metaprogramming layer in order to support more smoothly things like homegrown class systems (like the one I see in Grid, in the very first example in your homepage). So I would love to get feedback as we start to explore this space. I want Teal to remain a minimalistic and pragmatic project, so the goal is not to develop a super-general meta-programming system, but one that solves concrete problems Lua developers face when integrating Teal.
The definition of compiler has never assumed generating executable machine code. Already in the 1970s, Pascal compilers have generated P-code (a form of "bytecode" in Java parlance), which was then interpreted. In the 1980s, Turbo Pascal produced machine code directly.
I've seen the neologism "transpiler" being very frowned upon by the academic programming language community precisely because a compiler is a compiler, no matter the output language — my use of "compiler" there was precisely because of my academic background.
I don't mind the term "transpiler" myself if it helps you understand it's a source-to-source compiler, but then, you don't see people calling the Nim compiler, which generates C code then compiles it into machine code, a "transpiler", even though it is a source-to-source compiler. In the end, "compiler" is the all-encompassing term for a program that takes code in one language and produces code in another, be it high-level or machine language — and yes, that means that technically an assembler is a compiler as well. And since we're talking assembler, most C compilers do not generate executable machine code either: gcc produces assembly, which is then turned into machine code by gas. So gcc is a source-to-source compiler? Is Turbo Pascal more of a compiler than gcc? I could just as well add an output step in the Teal compiler to produce an executable in the output using the same techniques of the Pascal compilers of the 70s. I don't think that would make it more or less of a compiler.
As you can see, the distinction of "what is a transpiler" reduces to "what is source code" or "what is a high-level language", the latter especially having a very fuzzy definition, so in the end my sociological observation on the uses of "transpiler" vs. "compiler" tends to boil down to people's perceptions of "what is a Real, Hardcore Compiler". But being a "transpiler" or not doesn't say anything about the project's "hardcoreness" either — I'm sure the TypeScript compiler which generates JavaScript is a lot more complex than a lot of compilers out there which generate machine code.
That was indeed one of the motivations for GoboLinux after tinkering with hand-compiled software a lot. Uninstalling is a mere "rm -rf /Programs/ProgramName" :)
It's not by accident! In its original docs, Homebrew described itself as package management "the GoboLinux way".
Given how Homebrew has become this super-popular tool, its success makes me proud of Gobo's legacy (and a bit vindicated from all the people who told us "this model is crazy, it will never be usable!" :) )
> keeping all versions of everything is that you end up with problems when you're trying to build/use packages with a large pool of dependencies
Yes, it can be a pain! In recent years, we introduced Runner (https://gobolinux.org/runner.html) in GoboLinux as a way to address this kind of issue; a virtualization layer to present the expected dependencies at the right places.
I would say Gobo and NixOS follow roughly the same philosophy, with Nix adding the functional aspect on top, which is pretty neat. But yes, one of the motivations for Gobo was to make it easy to revert versions of programs, with commands for enabling/disabling their symlinks, and even keeping multiple versions at the same time. We didn't do full-system snapshots, but handled it on a program-by-program basis, which was our main interest at the time (tinkering with the latest window manager!).
> Isn't this what /opt is for though?
Pretty much yes; the idea was "/opt all the things!" (well, before the all-the-things meme existed — it was a long time ago!) and use symlinks to make everything appear as if it was installed in the "regular" Unix places (so that we wouldn't have to patch/reconfigure every single program).
GoboLinux has a long and cool story (I still use it!) but that's the tl;dr version of the motivation!
And why would they ever be the same? Writing "#s-2" you're treating -2 as a relative _offset_, not an index.
> Basically, some things are more "natural" with 1-based counting, but some aren't.
Yes, offsets are naturally zero-based, and indices (everywhere other than languages derived from the C tradition) are naturally 1-based. The reason why C and its descendants use zero-based indexes is because C mixes indexes with offsets (since offsets are the low-level primitive in machine language), so that given a pointer p, we have that p[i] and p+i are the same.
If instead C had not done that and used 1-based indexing like everyone else back then, I'm sure people today would be claiming how C is superior for providing both 1-based indexing with [] and 0-based offsets with +, since there are always scenarios where one leads to more natural expressions that the other, and how people mixing them up were clearly not suited for the subtleties of low-level programming in C, and should be instead using simpler languages with garbage collection and without pointer arithmetic. :)
No, because Lua is 1-based :) The last element is l[#l] (#l is "length of l"). Negative indices aren't really used in arrays, but are used in the string library, so given s = "hello"; s:sub(1,4) gives you "hell" and s:sub(-2,-1) gives you "lo".
Speaking of general purpose application programming, you might be interested in my new(ish) project Teal:
https://github.com/teal-language/tl
It's a statically typed dialect of Lua, which is compatible with all modern Lua versions.
The core compiler itself is one tl.lua file which can be added to any Lua project, and includes a Lua package loader that makes Lua's `require()` support .tl files, and there's also a tl CLI for generating .lua from .tl files.