Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supers are not lazily evaluated #11

Open
Pacman99 opened this issue May 16, 2023 · 8 comments
Open

Supers are not lazily evaluated #11

Pacman99 opened this issue May 16, 2023 · 8 comments

Comments

@Pacman99
Copy link
Member

Pacman99 commented May 16, 2023

nix-repl> pop.lib.pop { supers = [ { a = throw "err"; b = 5; } ]; }
error: err

An attribute in a pop containing an error shouldn't error out the entire pop. Other attributes should still be accessible even if one attribute errors out.

The following code should print out 5, but it would just error out now.

p = pop.lib.pop { supers = [ { a = throw "err"; b = 5; } ]; }
p.b

cc @fare

@fare
Copy link
Collaborator

fare commented May 17, 2023

That sounds like a bug indeed: the list of supers should be eagerly evaluated to resolve the multiple inheritance hierarchy, but the fields of the super itself shouldn't. Maybe the bug though isn't in the super handling, but in the casting of prototype-less record to pop prototype? Even then that would be a bug, but a different one.

@Pacman99
Copy link
Member Author

Maybe the bug though isn't in the super handling, but in the casting of prototype-less record to pop prototype?

I dont think so, I just used the plain attribute set as an example, but it happens even if that attrset was wrapped in a kPop.

pop.lib.pop { supers = [ (kPop { a = throw "err"; b = 5; }) ]; }

Also errors out.

@GTrunSec
Copy link

GTrunSec commented Aug 23, 2023

@fare Are there any inquiries pertaining to this matter? I also got the same problem when I trying embed POP into my instance. Thanks

@Pacman99
Copy link
Member Author

I opened this NixOS/nix#8364

@fare
Copy link
Collaborator

fare commented Oct 26, 2023

https://twitter.com/Ngnghm/status/1717684526720094339

Lacking the ability to compare structures or functions by pointer identity, or system-provided nonces as identity tags, the only reliable solution is user-provided labels with some naming conventions to retrieve some modularity.

@fare
Copy link
Collaborator

fare commented Nov 28, 2023

Akshully, we might be able to do proper pointer equality: https://code.tvl.fyi/about/tvix/docs/value-pointer-equality.md

@Pacman99
Copy link
Member Author

Yeah I just saw that thread! I might give that a try to see if we can fix this issue. I tried something similar with lists which sometimes worked, so hopefully this trick will work fully.

@fare
Copy link
Collaborator

fare commented Nov 28, 2023

Note that one part of the problem is ensuring that true is returned when the two are pointer-equal, the other part of the problem is ensuring that false is returned when they are not, instead of an error being thrown or an infinite branch taken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants