| 12 Jul 2023 |
 @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 |
 tea | In reply to @infinisil:matrix.org
Or maybe it should be scheduled already, so I have some pressure to get it done until then 🤔 I am up for pair coding if u need any help | 08:39:17 |
| tea | (I'm bored lol) | 08:39:22 |
|  @lyndeno:matrix.org joined the room. | 14:34:10 |
