Next version!

[hishamhm]

No description provided.

[github-actions]

Teal Playground URL: https://732--teal-playground-preview.netlify.app

[bjornbm]

I'm excited for this new release, but struggle to grasp the interfaces and probably other changes. Basically I don't see much updates/explanation in tutorial.md, neither of interfaces not the move to nominal types (#711, #708).

[euclidianAce]

From a quick glance I like the api changes and interfaces are a huge boon. Writing up some quick and dirty luv definitions (which is full of inheritance/interfaces) seems to be working well. I see interface where clauses are implemented as macros, which are also exposed via a new local macroexp foo(...) statement which after giving some thought is probably the best/lowest-amount-of-tying-users-of-teal-to-one-object-model way for a language like teal to add that sort of feature. Also nominal types are always a 👍 from me.

I do need to get back into the swing of working on teal related stuff, but I definitely fell into the got-a-real-job-and-now-have-less-time-to-work-on-hobby-projects trap that happens so often with open source.

All in all, looks great to me!

[catwell]

Same as @euclidianAce, real life (work + new kid) means I have little time for OSS but the changes I see in this branch are a lot of things I thought would be great for Teal.

Once it is a bit more stable I'll try it on my existing code bases in Teal.

[hishamhm]

@bjornbm tests and documentation are still pretty much missing, because I wanted to iterate as quickly as possible to experiment with the usability of these features... but once the dust settles we definitely need them!

[hishamhm]

@euclidianAce @catwell Thanks a lot for the feedback!! And, yeah, I totally get that sentiment — over the years I've accepted that my work on FOSS projects happens in bursts. When I find that I get a window of availability and motivation to work on this stuff, I try to get the most out of it. :)

For Teal, having a quiet time for the project since the last burst was a good thing as it allowed me to set priorities: seeing what are the gaps that people most often try to solve, etc. I think it's clear by now that the top two things missing in current Teal are interfaces and better nil handling. I don't think we'll get non-nilable types just yet, but it's the next thing on my mind. With --feat flags it should be easier to make gradual changes to the language in the future. This writeup has made the rounds recently and makes a good case for gradual language evolution via per-compilation-unit feature flags.

[hishamhm]

Also, speaking of writeups, it's funny that CI is failing because the tl.type_check function is exceeding the maximum number of upvalues per function in Lua 5.1. Looks like old Lua wasn't a fan of Carmack's long function style; I'll have to do some refactoring!

[hishamhm]

Update: it took me a big reorganization in d885f90 to get CI green. This is because the size of tl.tl started hitting size limits in both Lua 5.1 (number of upvalues) and Lua 5.4 (number of locals). The goal of the changes in this latest commit is to be able to finally break tl.tl into multiple files, but I wanted to do the reorg first to produce a sensible diff (which would let me more easily track the changes). The commit description includes more details on the internal changes.

[hishamhm]

Regarding "making the type system more nominal", here's one interesting example:

https://toot.kottman.xyz/@michal/111860362351389256

One thing I'm missing (or haven't yet found in docs) is "distinct type" (borrowing term from Nim) or integer based enum - e.g. local type LibraryErrorCode = distinct integer; function work():LibraryErrorCode

https://mastodon.social/@hisham_hm/111861339267098398

if you create a new nominal type for a base type like integer, it will be distinct across nominal types, but still be compatible with plain integer (so you can use the math. library etc)

This checks without errors in the master branch, but will check for Code against Age here in next:

local type Code = integer

local function get_code(): Code
end

local type Age = integer

local function get_age(): Age
end

local x: integer = get_code()
x = get_age()

local c: Code = get_code()
c = get_age()                         -- ERROR: in assignment: Age is not a Code

local a: Age = get_age()
a = get_code()                        -- ERROR: in assignment: Code is not a Age

[catwell]

I played a bit with the where clause on the current next branch, and I noticed that it doesn't work with generics. I mean that this works:

local type Success = record
    where self.error == false
    error: boolean
    value: integer
end

but not this:

local type Success = record<T>
    where self.error == false
    error: boolean
    value: T
end

It results in:

example.tl:2:11: missing type arguments in record<T>
example.tl:2:16: cannot index key 'error' in invalid 'self' of type self

Is that expected or do you intend to support it?

(Slightly related: can you release your FOSDEM slides? I know the video is probably broken, which is too bad, but the slides at least would be useful.)

[hishamhm]

@catwell thanks for the test case! I haven't really worked on the relationship between generics and interfaces/where yet, so that's a good starting point.

Is that expected or do you intend to support it?

I intended where to work alongside is, as in record __ is __ where, but having where on its own might be workable for unions. As for the generic there, I intend to support this test case, but I expect I'll need to place some limitations in the interactions between is ___ subtyping and generics. I'll probably over-restrict to be on the safe side first, then see what can be relaxed.

[catwell]

(Slightly related: can you release your FOSDEM slides? I know the video is probably broken, which is too bad, but the slides at least would be useful.)

The video was not broken \o/

[uramer]

How are where and __is intended to work for type declarations?