Hi, first, let me thank you for your time and willingness to engage in this discussion. For large part, let us agree to disagree, but one final question below, if you would have time to enlighten me. (Well, and technically also one more comment.)
Ludovic Courtès <[email protected]> writes: >> Out of curiosity, was it ever considered to do away with the whole >> (thunked) concept, and instead switch to explicit procedures taking the >> record instance? > > Nope! Never. Thunks are necessary to delay computation and to support > things like conditions on (%current-system). > > https://arxiv.org/abs/1305.4584 Here I do not understand. I have read the paper while back (and enjoyed it), but I still do not get it. Thunks (as implemented by (thunked)) are not necessary for the delayed computation no? Any lambda would suffice no? So wrapping it in a lambda of a single argument (the record instance) instead of zero (thunk) would achieve the same result, but allow removing all the magic. True, it would be more verbose when getting the value ((package-inputs pkg) pkg) versus current (package-inputs pkg) but it would achieve the same effect right? (I know I will not convince you to redo this, and I am not trying. I am just curious if there is still more magic with (thunked) I do not yet see.) > The goal from day 1 has always been to allow for declarative package > specifications that “look” obvious and have as little boilerplate as > possible. One could argue that when looking at (let ((services (modify-services ...))) (operating-system (inherit %base-os) (services services))) it is obvious what it *should* do (and what it looks like it is doing). Yet here we are. So while this change definitely satisfies the latter part of the goal, I still question alignment to the former. Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
