“Lua type masks” codes do not match “Lua types” codes – inconsequential?

[bjornbm]

Probably inconsequential – and I admit I didn't do the homework to try to figure out – but does it matter that “Lua type masks” do not match “Lua types” (in particular IS_TABLE and IS_STRING)? In contrast, the “Teal type masks” matach the “Teal types”.

https://github.com/teal-language/tl/blob/4478a82397f2b5a60424fea894f5fd9dd3387b27/tl.tl#L167C1-L209C1

tl.typecodes = {
   -- Lua types
   NIL                    = 0x00000001,
   NUMBER                 = 0x00000002,
   BOOLEAN                = 0x00000004,
   STRING                 = 0x00000008,
   TABLE                  = 0x00000010,
   FUNCTION               = 0x00000020,
   USERDATA               = 0x00000040,
   THREAD                 = 0x00000080,
   -- Lua type masks
   IS_TABLE               = 0x00000008,
   IS_NUMBER              = 0x00000002,
   IS_STRING              = 0x00000004,
   LUA_MASK               = 0x00000fff,
   -- Teal types
   INTEGER                = 0x00010002,
   ARRAY                  = 0x00010008,
   RECORD                 = 0x00020008,
   ARRAYRECORD            = 0x00030008,
   MAP                    = 0x00040008,
   TUPLE                  = 0x00080008,
   EMPTY_TABLE            = 0x00000008,
   ENUM                   = 0x00010004,
   -- Teal type masks
   IS_ARRAY               = 0x00010008,
   IS_RECORD              = 0x00020008,
   -- Indirect types
   NOMINAL                = 0x10000000,
   TYPE_VARIABLE          = 0x08000000,
   -- Indirect type masks
   IS_UNION               = 0x40000000,
   IS_POLY                = 0x20000020,
   -- Special types
   ANY                    = 0xffffffff,
   UNKNOWN                = 0x80008000,
   INVALID                = 0x80000000,
   -- Special type masks
   IS_SPECIAL             = 0x80000000,
   IS_VALID               = 0x00000fff,
}

[hishamhm]

@bjornbm Yeah, I noticed that mistake recently. My original intention was to provide those masks as a convenience for speedy processing of the tl types output for whatever code analysis tools came along to use them; the tl compiler itself does not use these masks, it just outputs the type values via tl types.

The VSCode plugin by @pdesaulniers uses those type values (but not the masks, I think), so if I were to change them to make the values fit the masks I would end up breaking his plugin. (Not sure about @euclidianAce's vim-teal?)

It would be a good idea to fix those numbers, but we'd probably need to add versioning info to tl types output and coordinate to make sure that the tooling around them doesn't break.

[hishamhm]

One first approach towards this issue we can do now (prior to reworking the numbers to make them more consistent) would be to drop those incorrect and unused mask entries from the compiler code.

[pdesaulniers]

The VSCode plugin by @pdesaulniers uses those type values (but not the masks, I think), so if I were to change them to make the values fit the masks I would end up breaking his plugin.

FWIW, I wouldn't mind changing the type values in the VSCode extension.

If this change is implemented, I can either:

• Tell users to upgrade to a more recent version of the tl compiler. Show a warning at startup if they are using an older version of the tl compiler.
• Modify the extension so that it uses different type values depending on the current version of the tl compiler.

(I already parse the output of tl --version at startup)

(Not sure about @euclidianAce's vim-teal?)

vim-teal does not make use of tl types. As far as I know, it only interacts with the compiler through tl check and tl gen. With that said, these type values might be used in other projects...