| Time |
Nick |
Message |
| 00:00 |
MTDiscord |
<exe_virus> Will do, might be a day or two till I have 30 minutes of self time in front of a computer |
| 00:00 |
MTDiscord |
<greenxenith> Yikes thats a lot of comments |
| 00:00 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> 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 |
<a.corp.serot> yes, i wrote it in my text editor so the syntax highlighting was better. i got carried away while doing it |
| 00:02 |
MTDiscord |
<wsor4035> basically https://discord.com/channels/369122544273588224/926231483155378176/1456498268073758924 |
| 00:03 |
MTDiscord |
<greenxenith> Please hold, reading a few text walls |
| 00:03 |
MTDiscord |
<a.corp.serot> i also wrote that a Lua DSL like LOVE (or was it LOVE2D?) could also be possible |
| 00:03 |
MTDiscord |
<wsor4035> https://tenor.com/view/x-men-origins-ryan-reynolds-deadpool-hugh-jackman-wolverine-gif-4753474 |
| 00:03 |
MTDiscord |
<a.corp.serot> which luatic was interested in |
| 00:04 |
MTDiscord |
<wsor4035> https://tenor.com/view/dance-dancing-elevator-the-office-gif-11036343 |
| 00:14 |
MTDiscord |
<greenxenith> 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 |
<a.corp.serot> is a custom type system really desired? |
| 00:15 |
MTDiscord |
<a.corp.serot> after writing allat i kinda feel that it's bad |
| 00:15 |
MTDiscord |
<greenxenith> Depends on what you mean by "custom type system" |
| 00:16 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> For example, it is difficult to write a bulk of the API without a Node type |
| 00:17 |
MTDiscord |
<greenxenith> Besides, I dont think any sane documentaion doesnt document its classes as types |
| 00:17 |
MTDiscord |
<a.corp.serot> custom type system as in we're defining one from scratch instead of using an existing one |
| 00:18 |
MTDiscord |
<greenxenith> (assuming I saw correctly) like shoehorning Typescript's types? |
| 00:18 |
MTDiscord |
<a.corp.serot> yes; or EmmyLua's or LuaLS's |
| 00:19 |
MTDiscord |
<a.corp.serot> i felt that the work of writing a custom type verifier would be pretty tedious |
| 00:20 |
MTDiscord |
<greenxenith> Is this more for the LSP side of things? |
| 00:20 |
MTDiscord |
<a.corp.serot> more so of preventing developers from writing conflicting types |
| 00:21 |
MTDiscord |
<greenxenith> I probably dont understand your usecase then; What problem does a type system actually solve? |
| 00:21 |
MTDiscord |
<greenxenith> (In a practical example, preferrably) |
| 00:24 |
MTDiscord |
<a.corp.serot> 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 |
<a.corp.serot> .s/this schema and content/its schema and content |
| 00:24 |
MTDiscord |
<greenxenith> What specifically wouldnt make sense in its type system? |
| 00:29 |
MTDiscord |
<a.corp.serot> 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 |
<greenxenith> Seems dubiously practical |
| 00:44 |
MTDiscord |
<a.corp.serot> - 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 |
<greenxenith> Well I did say both multiple types and casting |
| 00:45 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> And I suppose tuples is fair |
| 00:46 |
MTDiscord |
<a.corp.serot> 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 |
<greenxenith> Fair |
| 00:48 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> (This may also be a fault of how the docs are currently organized) |
| 00:49 |
MTDiscord |
<a.corp.serot> you can define it at register_abm too with how i've made the markdown format |
| 00:49 |
MTDiscord |
<a.corp.serot> though, registered_abm would feel a bit lonely XD |
| 00:49 |
MTDiscord |
<greenxenith> Right, I figured as much. Just an unfortunate example |
| 00:50 |
MTDiscord |
<greenxenith> Like, Node a a struct makes perfect sense. Its used everywhere. ParticleSpawnerDefinition?? What?? |
| 00:51 |
MTDiscord |
<greenxenith> (This is mostly a critique of the current API ref really) |
| 00:51 |
MTDiscord |
<a.corp.serot> i tried understanding particle spawner definition. i came out less of a person ;__; |
| 00:52 |
MTDiscord |
<greenxenith> 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 |
<greenxenith> And they are never labeled properly either |
| 00:52 |
MTDiscord |
<wsor4035> i was hopeing however we defined types they would be clickable to jump around, at least in the web version |
| 00:53 |
MTDiscord |
<greenxenith> Absolutely |
| 00:53 |
MTDiscord |
<greenxenith> But that should be skipped entirely for things like ABM and particle definitions. Those are basically named function parameters |
| 00:57 |
MTDiscord |
<a.corp.serot> 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 |
<greenxenith> Fair |
| 01:00 |
MTDiscord |
<greenxenith> No notes on the schema itself atm |
| 01:01 |
MTDiscord |
<a.corp.serot> 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 |
<greenxenith> Oh I didnt say it was necessarily good, I just have no notes :p |
| 01:01 |
MTDiscord |
<a.corp.serot> oh XD |
| 01:03 |
MTDiscord |
<a.corp.serot> 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 |
<exe_virus> 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 |
<a.corp.serot> i suppose you could also define that to have a globally accessible type name instead of trapped within register_abm() |
| 01:06 |
MTDiscord |
<greenxenith> Why would you need to reference an ABM definition as opposed to any other function parameter? |
| 01:08 |
MTDiscord |
<greenxenith> 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 |
<a.corp.serot> yeah, the format can probably allow for that. it makes more sense to me, at least |
| 01:09 |
MTDiscord |
<greenxenith> (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 |
<exe_virus> If it's reused, then yes it makes sense to write once and refer. If it's used once, then no. |
| 01:26 |
MTDiscord |
<exe_virus> 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 |
<mark.wiemer> 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 |
<mark.wiemer> 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 🙂 |
| 05:00 |
|
MTDiscord joined #luanti-docs |
| 07:48 |
MTDiscord |
<luatic> 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. |
| 11:43 |
|
mrcheese joined #luanti-docs |
| 23:45 |
|
mrcheese joined #luanti-docs |
