| 11 Jul 2023 |
 profpatsch | We could just follow suit | 14:20:34 |
 infinisil | tomberek: John Ericson: Joining? | 14:33:09 |
 John Ericson | sorry in a work meeting will be late :/ | 14:33:25 |
 @piegames:matrix.org | "TODO: refactor once something like Profpatsch's types-simple will land" what's types-simple, and when will it land? | 15:52:55 |
| @piegames:matrix.org | Ah, found it: https://github.com/NixOS/nixpkgs/compare/master...Profpatsch:nixpkgs:types-simple-WIP | 15:54:21 |
| profpatsch | piegames: notime, Eelco said he doesn’t want it | 16:08:40 |
| @piegames:matrix.org | Somebody else would have to veto in order to stop me (: | 16:10:13 |
| @piegames:matrix.org | I might be motivated to pick this up, unless somebody shows me another way to solve my problems described in https://discourse.nixos.org/t/the-module-system-is-dead-how-to-do-input-validation/30297/4 | 16:11:20 |
| profpatsch | piegames: An alternative with a slightly different design is https://code.tvl.fyi/tree/nix/yants/default.nix | 16:11:44 |
| @piegames:matrix.org | Yeah I've seen YANTS and didn't like it as much | 16:12:07 |
| profpatsch | The main difference is that types-simple is out-of-band, while yants is in-band | 16:12:11 |
| @piegames:matrix.org | wdym | 16:12:30 |
| profpatsch | which gives yants the (partial) ability to type-check functions | 16:12:37 |
| profpatsch | types-simple can only typecheck “data”, not functions | 16:14:19 |
| profpatsch | depends on what you want to do, for checkMeta only checking data should be enough | 16:14:47 |
| @piegames:matrix.org | Well ideally I'd like to use this for Nixpkgs configuration too, but merging :( | 16:16:05 |
| profpatsch | merging is different from typechecking | 16:16:53 |
| profpatsch | conflating the two is a big source of annoyance | 16:17:02 |
| @piegames:matrix.org | I know | 16:17:13 |
| @piegames:matrix.org | One thing that I'd really like to have is some type checking but with default values support. Because currently, there's only the module system which can do that, and instantiating a module system just for each package's meta is not something that is going to fly | 17:03:53 |
| profpatsch | piegames: I haven’t thought in-depth about that, but to me a merging algorithm is just a monoidal thingy | 17:15:27 |
| profpatsch | you can do a lot of things with that | 17:15:47 |
| profpatsch | e.g. (//) and attributes form a monoid | 17:16:14 |
| profpatsch | So does recursiveMerge and attrsets | 17:16:29 |
| profpatsch | s/attributes/attrsets/ | 17:16:35 |
| profpatsch | I bet you can fit defaults and mkForce etc in there, too | 17:17:03 |
| @piegames:matrix.org | Actually merging itself, and having that in the type system isn't that big of a deal IMO. Problems arise if you expect to merge values with inter-dependencies. Like, Nixpkgs config requires merging as there are multiple places where the configuration can be but, but they are all independent from each other so it's a lot simpler | 17:18:26 |
| profpatsch | priority is pretty simple to fit in, Priority { prio :: Int, value :: a } is a monoid by taking the value with the higher priority | 17:18:36 |
| @piegames:matrix.org | Oh, what you're saying is "default values are just merging with priority"? | 17:19:54 |
| @piegames:matrix.org | But how about default values without otherwise merging functionality | 17:20:11 |
