taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> (modify-phases '((foo . 0) (bar . 1) (baz . 2)) > (delete foo) > (replace bar 'x) > (add-before baz pre-baz 'y)) ;=> ((bar . x) (pre-baz . y) (baz . 2)) I like it! Let’s put it in (guix utils)? > ;;; phase-lambda > > (define-syntax phase-lambda > (syntax-rules () > ((phase-lambda ((arg (alist-entry ...)) > ...) > body ...) > (lambda* (#:key arg ... #:allow-other-keys) > (let-values (((alist-entry ...) > (let ((arg* arg)) > (values > (assoc-ref arg* (symbol->string 'alist-entry)) > ...))) > ...) > body ...))))) > > ;;; Usage example: > > (phase-lambda ((inputs (libx liby)) > (outputs (out))) > ...) > > ;;; effectively equivalent to: > > (lambda* (#:key inputs outputs #:allow-other-keys) > (let ((libx (assoc-ref inputs "libx")) > (liby (assoc-ref inputs "liby")) > (out (assoc-ref outputs "out"))) > ...)) > > > This saves the usual boilerplate of '(#:key inputs outputs > #:allow-other-keys)' and the subsequent `assoc-ref' uses. Clearly, this is something we must address. However, I’m uneasy with this solutions for two reasons: 1. The embedded ‘symbol->string’, and the fact that the developer no longer types in "foo" when the ‘inputs’ field has "foo" (as a string), making the connection non-obvious. 2. In the grand scheme of things, gexps make the problem moot: (lambda _ (frob-libs #$libx #$liby:include) (stuff-output #$output) ...) However, there’s a complication: currently we can change the ‘inputs’ field of a package (like ‘package-with-explicit-inputs’ etc. do), and its build script will get to see the new inputs, which is super convenient. Conversely, gexps currently end up hard-coding the output file name of the package directly in the build script, which prevents this kind of “input rewriting.” I don’t yet have a nice idea on how to solve that, but that’s an important thing to do. WDYT? Thank you, Ludo’.