IRC channel logs

2025-05-12.log

back to list of logs

<lechner>Hi, if an S-expression is by necessity evaluated twice, are there idioms for (i.e. ways to clearly identify) the earlier and the later evaluation?
<sham1>What do you mean by "evaluated twice"
<old>Evaluation that generate code to evaluate?
<old>sounds like a security nightmware lol
<lechner>sham1 / old / I wrote a new but undocumented shell integration helper that causes executables to accept a configuration record. In Guix, the configuration is evaluated twice---once when the system is deployed, and again at runtime (and inside the executable). It works great but looks funny. I'm trying to improve the optics
<sham1>I see
<old>lechner: can you show us? I don't understand what your integration is achieving
<lechner>old / on the configuration side, which is the one I asked about here, this welcome message is evaluated twice. The device path is substituted at configuration time so the person logging in knows which terminal they are on (i know that's also available via /proc/self/fd/0). The TERM variable is evaluated at runtime. https://bpa.st/H5LA#1L8-L12
<lechner>I cannot get rid of the first evaluation. it is needed to resolve other essentials like store paths
<lechner>as in the "greeter" field
<old>I'm not sure to understand what you mean by configuration time. But I guess you can do the first evaluation in a syntax-transformer during expansion and compilation and the second evaluation durning runtime?
<lechner>old / the evaluations work fine. (the first at 'guix deploy', for me.) my question was more about visual separation