!9IQChSjwSHXPPWTa:lix.systems

Lix

1103 Members
Lix user channel. Feel free to discuss on-topic issues here and give each other help. For matrix.to links to the rest of the Lix channels, see: https://wiki.lix.systems/books/lix-organisation/page/matrix-rooms295 Servers

Load older messages


SenderMessageTime
1 Dec 2025
@piegames:flausch.socialpiegamesI'd say the theory agrees with you, but I wouldn't bet on the code doing the sane thing until I've seen it08:53:39
@piegames:flausch.socialpiegameshttps://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/eval.cc#L1762 at last callFunction requires the functor to take to arguments, so any deviation from that must come from some autocall jank09:02:55
@piegames:flausch.socialpiegameshttps://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/eval.cc#L1820 indeed, autoCallFunction only calls __functor with one single argument09:05:32
@piegames:flausch.socialpiegames @niko:nrab.lol can you please file an issue for your finding? So that I don't forget it when I'll come around to sanitizing the autocaller 09:06:42
@piegames:flausch.socialpiegames
In reply to @piegames:flausch.social
https://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/eval.cc#L1820 indeed, autoCallFunction only calls __functor with one single argument
Well, it does the right thing in spirit, because it directly recurses so if the functor takes two arguments as usual then the code will behave correctly. It's just that if it isn't, there is an early return from the recursion which prevents the code path that would be inspecting the inner function
09:08:10
@piegames:flausch.socialpiegames One interesting question is what to do with a functor like { __functor = self: b: 1; }, where the inner lambda does not destructure its attributes and thus cannot be autocalled. The probably correct result would be b: 1, which might be confusing. The alternative would be to only treat the functor as a function when it applies and thus leave the attrset unchanged, but that might be another can of worms 09:11:31
@niko:nrab.lolniko ⚡️
In reply to @piegames:flausch.social
One interesting question is what to do with a functor like { __functor = self: b: 1; }, where the inner lambda does not destructure its attributes and thus cannot be autocalled. The probably correct result would be b: 1, which might be confusing. The alternative would be to only treat the functor as a function when it applies and thus leave the attrset unchanged, but that might be another can of worms
I really don’t like how __functor = _: _: 1 and __functor = _: {...}@_: 1 have different auto-call semantics
09:15:58
@niko:nrab.lolniko ⚡️Can we like, not auto-call functors in the first place? And kill deep auto-calls while we’re at it? :^)09:17:25
@niko:nrab.lolniko ⚡️
In reply to @piegames:flausch.social
@niko:nrab.lol can you please file an issue for your finding? So that I don't forget it when I'll come around to sanitizing the autocaller
It is done
09:45:35
@piegames:flausch.socialpiegames
In reply to @niko:nrab.lol
I really don’t like how __functor = _: _: 1 and __functor = _: {...}@_: 1 have different auto-call semantics
To be fair these have subtly different semantics even outside of auto-calling, so I would argue that bit not to be an auto-call issue
09:53:59
@niko:nrab.lolniko ⚡️
In reply to @piegames:flausch.social
To be fair these have subtly different semantics even outside of auto-calling, so I would argue that bit not to be an auto-call issue
I think asserting an argument is an attrset is on a different level to whether autocalling takes place or not
09:54:53
@niko:nrab.lolniko ⚡️ At least I’d personally expect all functions to be auto-called, or none 09:55:17
@piegames:flausch.socialpiegames
In reply to @niko:nrab.lol
At least I’d personally expect all functions to be auto-called, or none
Well that's already not the case unfortunately https://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/eval.cc#L1831
10:05:20
@niko:nrab.lolniko ⚡️
In reply to @piegames:flausch.social
Well that's already not the case unfortunately https://git.lix.systems/lix-project/lix/src/branch/main/lix/libexpr/eval.cc#L1831
Oh I know, I’m very much not a fan of auto-calling in the first place, but even my bias aside it has a bunch of sharp edges besides e.g. the blatant bug with functors
10:08:17
@piegames:flausch.socialpiegamesHonestly auto-calling should be ripped out and replaced with some dedicated parametrized top-level entry point mechanism10:19:33
@piegames:flausch.socialpiegames And functors, sigh 10:19:48
@helle:tacobelllabs.nethelle (just a stray cat girl)auto-calling is scary stuff imo10:28:24
@piegames:flausch.socialpiegamesUnfortunately I'm a pretty big user of it :D11:09:11
@piegames:flausch.socialpiegamesIt's great when you're using Nix as a data pipeline scripting language11:09:30
@raitobezarius:matrix.orgraitobezariusnixpkgs and normal package uses a lot of autocalls as well11:32:14
@raitobezarius:matrix.orgraitobezariusbut simple shallow autocalls usually11:32:22
@raitobezarius:matrix.orgraitobezariusit would make sense for flaker maybe to support measuring the depthness of the autocalls11:32:30
@raitobezarius:matrix.orgraitobezariusfor non-flakes entrypoints i suppose11:32:35
@piegames:flausch.socialpiegamesCan this be done with static analysis?11:33:36
@raitobezarius:matrix.orgraitobezariusi don't believe so11:33:44
@piegames:flausch.socialpiegamesCan you give some examples?11:33:58
@raitobezarius:matrix.orgraitobezariuswe must hook some reporting facility in lix that you can exploit11:33:53
@raitobezarius:matrix.orgraitobezariusold-style tests entrypoints11:34:08
@raitobezarius:matrix.orgraitobezariusin nixpkgs11:34:13
@piegames:flausch.socialpiegamesBecause without a standardized way to enumerate all entry points, finding usage through Flaker will be tricky11:34:26

Show newer messages


Back to Room ListRoom Version: 10