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
C API: Improve value initializers #10577
Comments
The issue with this statement is that this is an implementation detail. It's not guaranteed to be the case over alternative Nix implementations, or even changes to the existing implementation, which is what the C API is designed to avoid. (Tbh, re #10499, having a distinction between thunked and non-thunked feels a bit iffy to me as well, because this is harder to abstract over in other languages; it'd feel more comfortable personally to have the entire API re-thunked instead of adding more bits and pieces on top. It's unstable for a reason :)) |
That's fair, but I'm having trouble to imagine an implementation that would allocate in an initialization routine. I suppose this would involve some serious "adapter" logic to bridge a significant mismatch between the memory model of an alternate implementation and a memory model that's close to what the C API suggests.
This is not an explicit goal, though I would like for this to work as well as it can.
I'm ok to discuss here, but might be more effective to comment there. By "re-thunked", do I understand correctly that you agree with the goal of having more lazy behavior, and also wish to remove the functions or behaviors that are unnecessarily strict? |
I'd counter that "applying an argument to a lambda/callable" is, in fact, not strongly an "initialization routine", and doesn't
As I said, "or even changes to the existing implementation." - there's no guarantee this may change in the future with a better interpreter.
Having one set of functions that are all lazy, rather than a set that is lazy and a set that is strict, is my preference; but I can see reasons for wanting both. |
The purpose was to initialize an already allocated value to be a thunk. Laziness requires that that's a simple operation, but non-strictness does not. I suppose an evaluator might want to be more eager in some cases? I don't think a requirement to have both the simple and eager behavior would be a burden on evaluators, but I'll cut it short here because I already agreed, and I think we've found a potential concrete reason - even better. Thank you for the discussion and clarification! |
Is your feature request related to a problem? Please describe.
--- #10537 (comment)
Describe the solution you'd like
--- #10537 (comment)
Describe alternatives you've considered
Additional context
Priorities
Add 👍 to issues you find important.
The text was updated successfully, but these errors were encountered: