| 8 Jul 2021 |
 Las | Thanks | 16:27:48 |
| Las | That link mentions static typing though, not gradual typing | 16:28:20 |
 balsoft | What I would love to see is a new distro, built from scratch, with Nickel at its core. | 16:28:24 |
| balsoft | Then we can evaluate how that worked out and perhaps bring many improvements from there over to Nix(OS) | 16:28:46 |
| balsoft | The most basic linux distro (maybe with busybox and musl, for extra simplicity) shouldn't be too long to make. | 16:29:22 |
| balsoft | * The most basic linux distro (maybe with busybox and musl, for extra simplicity) shouldn't take too long to make. | 16:29:30 |
| balsoft | Just something without init, that launches into a user-specified executable, all instantiated by nickel and realised by nix. | 16:30:12 |
| balsoft | If it turns out Nickel is so great at this that it's feasible to make something more complex -- great, we have another sister project that we can mutually benefit from. If not, learn from mistakes, find the good parts and bring them to NixOS. | 16:31:30 |
| Las | I think even if you don't use Nickel in NixOS, you could perhaps use its runtime for Nix, so that there's less duplication, because AFAICT you can map any Nix code to equivalent Nickel code. The reason I asked in the first place is because currently Nix evaluation is horribly slow. | 16:31:45 |
| balsoft | Huh? | 16:32:06 |
| balsoft | For me, the only "horribly slow" part is when IFD is involved. | 16:32:16 |
| balsoft | And that can be fixed without a new language. | 16:32:23 |
| Las | Yeah, you could just fix the interpreter | 16:32:37 |
| Las | but you could perhaps reuse the one in Nickel, was my idea | 16:32:47 |
| Las | Does evaluating your system configuration not take over 1 GiB of RAM? | 16:33:01 |
 Mic92 (Old) | Yeah. Everything evaluates single threaded and the gc cannot really garbage collect packages while evaluating. | 20:46:22 |
| 9 Jul 2021 |
 siraben | I want to look into literature on gradual typing in general | 05:12:54 |
| siraben | is there an STLC version of gradual types? something simple so that I can see what kinds of metatheoretical properties are usually proved (in type systems it's usually progress and preservation) | 05:13:37 |
 manveru | i dunno, but it seems nickel can't express something like { rules | Record Str -> #Rule } (or however that'd be written) to define that i simply want a record with user-chosen keys but specific value types... | 09:40:43 |
| manveru | basically rules = mkOption { type = attrsOf (submodule {name, ...}: { ... }; }; in nix | 09:42:24 |
| manveru | dhall had the same problem, which is why i gave up on that :| | 09:43:06 |
| manveru | so i'll stick with Nix and CUE for now, since they can work with such data more easily | 09:43:44 |
| manveru | garbas: are there any plans regarding that? I looked through the nickel docs and examples and didn't find any mention... | 09:46:55 |
 garbas | In reply to @manveru:matrix.org
garbas: are there any plans regarding that? I looked through the nickel docs and examples and didn't find any mention... I think Yann had some plans about this, but I think he just didn't have the time to look at this usecase. | 09:50:50 |
| garbas | In reply to @garbas:matrix.org
I think Yann had some plans about this, but I think he just didn't have the time to look at this usecase. Could you please create an issue about it to make sure Yann does not forget to look at this usecase? | 09:51:33 |
| manveru | In reply to @garbas:matrix.org
Could you please create an issue about it to make sure Yann does not forget to look at this usecase? sure, will do that :) | 09:51:51 |
|  vika (she/her) 🏳️⚧️ set a profile picture. | 16:38:42 |
| 10 Jul 2021 |
|  kreyren joined the room. | 08:35:11 |
| Mic92 (Old) changed their display name from Mic92 to Mic92 (Old). | 14:02:19 |
|  Mic92 joined the room. | 14:36:33 |
