Time Nick Message 00:00 MTDiscord Will do, might be a day or two till I have 30 minutes of self time in front of a computer 00:00 MTDiscord Yikes thats a lot of comments 00:00 MTDiscord basically just copy paste the example you posted previously, i could do it but i would rather it be under your name 00:01 MTDiscord basically just copy paste the example you posted previously, i could do it but i would rather it be under your name 00:02 MTDiscord yes, i wrote it in my text editor so the syntax highlighting was better. i got carried away while doing it 00:02 MTDiscord basically https://discord.com/channels/369122544273588224/926231483155378176/1456498268073758924 00:03 MTDiscord Please hold, reading a few text walls 00:03 MTDiscord i also wrote that a Lua DSL like LOVE (or was it LOVE2D?) could also be possible 00:03 MTDiscord https://tenor.com/view/x-men-origins-ryan-reynolds-deadpool-hugh-jackman-wolverine-gif-4753474 00:03 MTDiscord which luatic was interested in 00:04 MTDiscord https://tenor.com/view/dance-dancing-elevator-the-office-gif-11036343 00:14 MTDiscord First notes: * userdata is not always hidden and may be important (such as player objects). * Lua tables are arrays and/or hash maps. Specifically defining tuples as a type, and using "lists" and "mappings" instead of either the official designation or something familiar (list is ok, but "mapping" is out of place when it is usually just "maps" or "dictionaries"), seems odd. * I assume the practical reason for Unions is when multiple 00:14 MTDiscord types are allowed, or type casting (such as strings/numbers). * I would avoid getting into things like traits. Rust is cool but complex. KISS. * Examples should definitely be separate from descriptions as items. Some parsers may opt to omit examples (such as IDEs). * Organization and scope is a discussion that does need to happen And I am only 55 lines in 😩 00:15 MTDiscord is a custom type system really desired? 00:15 MTDiscord after writing allat i kinda feel that it's bad 00:15 MTDiscord Depends on what you mean by "custom type system" 00:16 MTDiscord At minimum we need to be able to define types. In my opinion, that includes custom classes. Beyond that is optional. But that is mostly what you have written anyway. 00:17 MTDiscord For example, it is difficult to write a bulk of the API without a Node type 00:17 MTDiscord Besides, I dont think any sane documentaion doesnt document its classes as types 00:17 MTDiscord custom type system as in we're defining one from scratch instead of using an existing one 00:18 MTDiscord (assuming I saw correctly) like shoehorning Typescript's types? 00:18 MTDiscord yes; or EmmyLua's or LuaLS's 00:19 MTDiscord i felt that the work of writing a custom type verifier would be pretty tedious 00:20 MTDiscord Is this more for the LSP side of things? 00:20 MTDiscord more so of preventing developers from writing conflicting types 00:21 MTDiscord I probably dont understand your usecase then; What problem does a type system actually solve? 00:21 MTDiscord (In a practical example, preferrably) 00:24 MTDiscord i think that the docs should be validated in this schema and content. one part of the content is the type system. if a luanti dev wrote something that doesn't make sense in its type system, the burden of catching that is then the reviewers. it'd be nice if machines can do part of the job by validating if the type assigned to a symbol is valid. 00:24 MTDiscord .s/this schema and content/its schema and content 00:24 MTDiscord What specifically wouldnt make sense in its type system? 00:29 MTDiscord i showed how T exclude S can be used to say that something accepts subtypes of T except S. if you were to write something like number exclude string it should be erroneous. ofc this is a really trivial example, but i expect that the types luanti have be too large to quickly catch bad A exclude B uses 00:44 MTDiscord Seems dubiously practical 00:44 MTDiscord - i vaguely remember someone saying luanti shouldn't need to expose what the underlying types of classes are. i couldn't come up with a probable usecase for exposing that detail. - i've divided into tuples, lists and mappings because lua tables are more flexible and powerful than mere maps/dicts. tuples can't be captured in a single variable, which i defined it because EmmyLua/LuaLS type system suffered pretty badly from their 00:44 MTDiscord inability to express that well. - type casting is not the reason i have unions. we need unions because some stuff simply accepts many types. consider Color for example, that can be expressed in many ways. how do we define Color? it's a union of ColorString, ColorTable ({r=, g=, b=}) and ColorNumber. 00:45 MTDiscord Well I did say both multiple types and casting 00:45 MTDiscord Usecase for userdata is the fact that you cant modify it. Its mostly useful to point out when something returned is immutable 00:46 MTDiscord And I suppose tuples is fair 00:46 MTDiscord string-number coercion shouldn't be encouraged tbh and immutable should hold for other classes too because surely modifying a table-based class is erroneous 00:47 MTDiscord Fair 00:48 MTDiscord Next note: (Not necessarily a fault of your proposition) I strongly dislike defining things like ABMDefintion as a standalone struct. NodeJS has a bad habit of doing this as well. ABMDefinition will NEVER be used anywhere else. It is not really a struct, its a parameter table 00:49 MTDiscord (This may also be a fault of how the docs are currently organized) 00:49 MTDiscord you can define it at register_abm too with how i've made the markdown format 00:49 MTDiscord though, registered_abm would feel a bit lonely XD 00:49 MTDiscord Right, I figured as much. Just an unfortunate example 00:50 MTDiscord Like, Node a a struct makes perfect sense. Its used everywhere. ParticleSpawnerDefinition?? What?? 00:51 MTDiscord (This is mostly a critique of the current API ref really) 00:51 MTDiscord i tried understanding particle spawner definition. i came out less of a person ;__; 00:52 MTDiscord Its actually bonkers how many definitions are separated in the reference so you have to jump around to figure out what to pass to a function 00:52 MTDiscord And they are never labeled properly either 00:52 MTDiscord i was hopeing however we defined types they would be clickable to jump around, at least in the web version 00:53 MTDiscord Absolutely 00:53 MTDiscord But that should be skipped entirely for things like ABM and particle definitions. Those are basically named function parameters 00:57 MTDiscord i wrote in my proposed markdown formats that extra constraints/contracts/whatever should be a thing, but I'm thinking now that it should be in the description for now and later added (like a V1.1 big update) to be machine parseable because i don't think it can be figured out within reasonable time. 00:59 MTDiscord Fair 01:00 MTDiscord No notes on the schema itself atm 01:01 MTDiscord yeah, i expected that the schema itself is good now esp the markdown-custom one if you imagine that the work of parsing it is magically already completed 01:01 MTDiscord Oh I didnt say it was necessarily good, I just have no notes :p 01:01 MTDiscord oh XD 01:03 MTDiscord as for referencing other entries in descriptions, that is gonna be hard if you need to reference stuff like ABM definitions defined as a function parameter type as it would be smth like core.register_abm()::Definition or something verbose like that 01:03 MTDiscord Yeah, my goal was originally to get us to adopt a custom markdown format, and then apply a standard XML or Json schema to the parsed result, so no need to worry about schema yet, cause that's super easy once we have a format we like 01:05 MTDiscord i suppose you could also define that to have a globally accessible type name instead of trapped within register_abm() 01:06 MTDiscord Why would you need to reference an ABM definition as opposed to any other function parameter? 01:08 MTDiscord I mean, either way at the very least the ABM definition should be co-located with the register_abm function. I just see no reason for it to be its own standalone struct when nothing else uses it. 01:08 MTDiscord yeah, the format can probably allow for that. it makes more sense to me, at least 01:09 MTDiscord (A function parameter like "options" a la NodeJS functions is technically a struct, sure. But making an entire ABMDefinition struct feels unnecessary to me) 01:25 MTDiscord If it's reused, then yes it makes sense to write once and refer. If it's used once, then no. 01:26 MTDiscord The question is the cutoff - when does it make sense to lift something far from the function parameter list, like a node table def 03:47 MTDiscord I don't think we have the capacity to incorporate complex exclusion types like this. It will be simpler, e.g. int, number, nil, number[3, 10] (any number from 3 to 10, inclusive), int[3, 10) (any int from 3 to 10, inclusive on 3, exclusive on 10). Probably enums too. That's about as complex as I think we can handle for a while until we have a very clear foundation upon which to build more complex types. 03:50 MTDiscord ideally even if something is moved far from the func, it's easy to jump to that distant location from the func. With static HTML that's hard. With our initiative it should be easy to turn typedefs into links both in the HTML site and the LSP data 🙂 07:48 MTDiscord A type system can greatly improve developer experience. The idea is that we could then generate Teal, TS, whatever typedefs from it. > and immutable should hold for other (not all) classes too because surely modifying a table-based class is erroneous it is not necessarily (e.g., giving an entity instance a custom on_step is essentially completely fine), but we might want to be able to make it be in some cases.