Re: Some macros to make package definitions prettier

[Taylan Ulrich Bayırlı/Kammer]

"Thompson, David" <address@hidden> writes:

>> (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")))
>>     ...))
>
> I'm not sure I like combining the alist destructuring part of this
> macro.  IMO, 'phase-lambda' could just take care of the 'lambda*'
> boilerplate, and maybe another macro ('alist-let'?) to reduce the
> 'assoc-ref' usage.

So we have

(phase-lambda ((inputs (libx liby))
               (outputs (out)))
  body)

vs. something like

(phase-lambda (inputs outputs)
  (alist-let ((inputs (libx liby))
              (outputs (out)))
    body))

which consists of two parts which are principally orthogonal.

I suspect that the above combination will be the overwhelming majority
of both these macros' use-cases if we split them, meaning we will have
done something impractical for the sake of a principle.

In fact the above implied definition of `alist-let' is still contrived
for this special case; if I really implemented a stand-alone
`alist-let', I would probably not make it support multiple clauses like
that, meaning the code would look something like:

(phase-lambda (inputs outputs)
  (alist-let inputs (libx lib)
    (alist-let outputs (out)
      body)))

which is unpleasant.

Others who have more experience with the larger codebase of Guix (or
even just Scheme codebases in general) should tell me whether my attempt
at pragmatism and the "You Ain't Gonna Need It" mentality is mistaken
here, but I think the `phase-lambda' that subsumes `alist-let' is the
best choice because that will cover our actual use-cases the best.

Taylan