| 12 Jul 2023 |
raitobezarius | and Cue has a lot of shortcomings when it comes to property checking I believe | 15:40:02 |
raitobezarius | some stuff is hard to spec | 15:40:09 |
@yannham:matrix.org |
To be frank, one of my hidden pleasure was that the module system is turing complete, and that people do not have to learn about functional programming to use it in NixOS.
On that I agree - recursive merging is just equivalent to functions in expressivity, but it's more natural to write configurations this way (also makes things more inspectable and easier to override if done ).
| 15:42:20 |
@yannham:matrix.org |
and Cue has a lot of shortcomings when it comes to property checking I believe
Ah right, I believe it's quite hard to encode custom validator beyond the builtin combinators. I think you can do something like write validation functions in Go and then glue things together at the scripting layer but it's suddenly not that simple anymore
| 15:45:30 |
profpatsch | yannham: fwiw, dhall has import-boundary caching of the reduced AST | 15:45:33 |
profpatsch | And it turns out it’s a pretty expensive operation in many practical use-cases, because partially applied functions tend to blow up a lot | 15:46:00 |
profpatsch | which is something the coq-people had figured out years ago from what I heard | 15:46:43 |
nbp | yannham: Nix achieved maximal laziness in the past using the ATerm library (which apparently is no longer packaged in Nixpkgs 😂). The principle of it was based on hash-cons. One thought I had before, was that the Nix evaluator could hash the expression, the environment, and just cache the result of the top-level evaluations. | 15:46:53 |
profpatsch | At least aspiwack said something along those lines | 15:47:03 |
nbp | This While this might not work as well on NixOS, this might save a lot on function applications for Nixpkgs. | 15:47:50 |
nbp | Which is a big part of NixOS evaluation too … | 15:48:20 |
profpatsch | nbp: even for string concatenation some more lazy operations could be worth it, I started an experiment a while ago https://gist.github.com/Profpatsch/afb8018c504a5c775446800bb13b0eaa | 15:48:36 |
profpatsch | it uses the dlist-trick | 15:49:29 |
nbp | For Nixpkgs what might be worth is lazy-update operator lookup for attribute names. | 15:49:41 |
@yannham:matrix.org |
yannham: fwiw, dhall has import-boundary caching of the reduced AST
Yeah, it's already something. But by incremental I really mean, in one file, you have a big configuration with recursive fields (might not be actually recursive, just a DAG, but fields that depend on other fields at least). You change enable to true to enable = false or greetings to "Hello, Plutus", and you want to recompute the least amount of stuff. This is on another level.
And it turns out it’s a pretty expensive operation in many practical use-cases, because partially applied functions tend to blow up a lot
From what I recall, I think this is a problem quite specific to dhall: basically their normal form representation which is cached isn't able to represent sharing, so you have to substitute everything and you end up with sometimes exponential blow up.
| 15:50:30 |
profpatsch | yes, you’d need sharing | 15:52:40 |
@yannham:matrix.org | nbp: yes I read Eelco's paper, but I believe this was a very long time ago. I'm curious how it would fare today, on current Nixpkgs or a NixOS configuration. Hashconsing everything is a trade-off, and it'll probably slow down the computation from scratch. Might still be fine if the gain in incremental evaluation is big enough. | 15:52:44 |
profpatsch | but it’s a hard problem, no? | 15:52:46 |
nbp | yannham: I think that's part of the reason for removing it. | 15:53:23 |
@yannham:matrix.org |
but it’s a hard problem, no?
Honestly, I don't really know. Like this, I would be tempted to say: hash-consing could be one way (especially given that Dhall has semantic hash). Another way could be to not necessarily cache normal forms, but allow things with remaining let-bindings. But Gabriella is a smart person, so I'm most definitely missing something. Could also be due to a conflicting design constraint elsewhere that requires cached values to be normal forms (or at least makes it harder if it's not the case). Arnaud probably knows better
| 15:57:01 |
@yannham:matrix.org | *
but it’s a hard problem, no?
Honestly, I don't really know. Like this, I would be tempted to say: hash-consing could be one way (especially given that Dhall has semantic hashes). Another way could be to not necessarily cache normal forms, but allow things with remaining let-bindings. But Gabriella is a smart person, so I'm most definitely missing something. Could also be due to a conflicting design constraint elsewhere that requires cached values to be normal forms (or at least makes it harder if it's not the case). Arnaud probably knows better
| 15:57:13 |
infinisil | In reply to @phaer:matrix.org Yes, "just" the implementation work left 😄 The implementation is not too hard really! I'll try to prioritize this :D | 17:06:00 |
infinisil | As discussed in the previous NAT meeting, once the PR is done, I'll schedule a meeting with the NAT to do a final review and merging | 17:08:57 |
infinisil | Anybody else welcome to join too of course, call it a merge party :P | 17:09:27 |
infinisil | Or maybe it should be scheduled already, so I have some pressure to get it done until then 🤔 | 17:09:47 |
| @teutat3s:pub.solar left the room. | 21:23:53 |
infinisil | Today I wrote some docs for the overall Nixpkgs file structure in the RFC 140 Part 1 PR: https://github.com/NixOS/nixpkgs/pull/237439/files/cf0ea317469501804a139ef6d267f4dcdbbd29dc#diff-d9e77bfcb681fae6baf681117c55d2b9119546a2a8727a876a8b497fa69dcd90 | 23:20:49 |
| 13 Jul 2023 |
Robert Hensing (roberth) | he/hello, I'm nixpkgs, by/bye | 19:53:16 |
infinisil | Robert Hensing (roberth): Slippery fingers? :P | 22:32:06 |
| 14 Jul 2023 |
@piegames:matrix.org | infinisil: Ping me for review on RFC 140 once you're done with all your current items | 08:35:19 |