guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some macros to make package definitions prettier


From: Ludovic Courtès
Subject: Re: Some macros to make package definitions prettier
Date: Thu, 26 Feb 2015 00:32:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

address@hidden (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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]