-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next version! #732
base: master
Are you sure you want to change the base?
Next version! #732
Conversation
Teal Playground URL: https://732--teal-playground-preview.netlify.app |
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 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! |
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. |
@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! |
@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 |
Also, speaking of writeups, it's funny that CI is failing because the |
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. |
Regarding "making the type system more nominal", here's one interesting example: https://toot.kottman.xyz/@michal/111860362351389256
https://mastodon.social/@hisham_hm/111861339267098398
This checks without errors in the 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 |
I played a bit with the
but not this:
It results in:
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.) |
@catwell thanks for the test case! I haven't really worked on the relationship between generics and interfaces/
I intended |
The video was not broken \o/ |
How are |
25cea1d
to
9cd464e
Compare
88918b2
to
e69d91b
Compare
f9ceea1
to
fbac8f3
Compare
f462b62
to
e297db7
Compare
Instead of treating nominal records nominally and all other nominal types structurally, with this commit we treat all nominal types nominally except for unions, which are treated structurally. Give this branch a try in your codebase and let me know your impressions!
This allows for a pattern where we can localize a record and load and alternative implementation on top of it. Fixes #759.
This makes me think if this should happen implicitly...
This triggered during debugging because show_type for two string with the same typeid didn't match.
The heuristic was only comparing against nominal types; if a non-nominal type such as `(self: integer)` was used, it was silently accepted as a method and promoted to the `self` type.
Thanks @svermeulen for the report!
59ad305
to
f6f992f
Compare
This matches the behavior of master. Can't make a simple regression test for this one because that would be dependent on unspecified behaviors of the parser and type-checker. Fixes #795.
Introduces a special internal type, to be used only as the node.expected type in boolean contexts such as `if _ then`. It behaves exactly like boolean except that type variables do not infer to it. See #768.
No description provided.