some improved signatures

[fperrad]

No description provided.

[github-actions]

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

[hishamhm]

@fperrad Thanks!!

I'm not sure regarding 2593fff. The Lua standard library does accept plain numbers in most (all?) places where an integer is expected. It checks at runtime whether the number has an integer representation. That is, this works: t = {1, 3}; table.insert(t, 2.0, 10); print(t[2]). Making Teal's definitions stricter than Lua's would cause users to add unnecessary casts or inefficient conversions. I've been generally wanting to represent in the definition what the actual behavior is, so as a rule of thumb I've been using integer in return types when Lua functions return actual integer values, and number in argument types where any "number with an integer representation" is accepted.

There might be inconsistencies in my definitions (I decided on purpose to grow it organically on an as-needed basis instead of trying to sit down and translate the entire Lua manual at once), but in general I've been trying to match the actual Lua behavior, to avoid annoying developers with correct code getting rejected by an overly-strict definition. That's also why you see that definitions that have enums do so in order to detect the types of other arguments/returns, not just to force a subset of values (and even then the last case of the poly is often a raw STRING to allow for non-literal arguments as a fallback). Realistically though, I expect some of those enum arguments in the standard library to only ever be used with literals...

It's a game of balance, of course. You could argue that our current definition of require is overly strict (I've been thinking of accepting your dynamic-require patch but add a warning if it is used without a cast to set a proper type, or something like that).

Ultimately, it's a question of wearing two different hats: the compiler author needs to implement the language exactly as it is, even if it allows users to write bad code. The language designer tries to design a language that, among other concerns, nudges users towards writing good code. For the standard library definitions, I feel more like a compiler writer (implementing Lua's standard library) than a language designer.

I'll review your PR item by item and cherry-pick the changes I feel are "safe". Thanks again!

[hishamhm]

@fperrad I gave this more thought and decided to go ahead with your integer suggestions, since they do give the programmer more type information (e.g. with autocomplete) making it easier to use the standard library as intended.

I have adapted your changes to my next branch, though, since I have successfully ported the standard library definitions to Teal itself (looks like the language's type system has become rich enough to represent that without major internal hacks!)

I've added commits crediting you here: https://github.com/teal-language/tl/tree/next