Maxime Devos <maximede...@telenet.be> writes:
> Do you mean #~#$fa:output here?
Yes, I did. Sorry, my fingers have minds of their own, and the
gexp syntax, in particular, really runs counter to their memory.
>> (file-append pkg:output "/path")
>
> This one is only possible if file-append becomes syntax instead of a
> procedure.
I did not expect this to be particularly possible, but I find it
aesthetically and intuitively pleasing enough to propose it anyway.
>> (file-append (list pkg "output") "/path")
>
> Possible, but seems semantically wrong to me -- what's a list doing in
> a file-manipulating procedure?
It need not be a list, but I do think it makes sense inside the
file-append, rather than a modification to file-append’s results, as is
currently the case. I picked list because it was being used elsewhere to
explicitly select a derivation’s output.
> My bikeshed proposal:
>
> (file-append (output glibc "static") "/lib/...")
>
> Here, 'output' is a procedure constructing some kind of object.
> This would also be useful outside 'file-append', as it allows
> programmatically constructing equivalents #~#$pkg:output for multiple
> 'output' (there was some package definition some while back where this
> would have been useful).
>
> This 'output' could perhaps also be used in 'inputs' / 'native-inputs'
> fields. YMMV.
I like this, and would prefer it over the ‘list’ proposal. I’m
not sure how to implement it given my limited knowledge of Guix
internals, though. Special-casing a list inside of file-append was
fairly straightforward and solved the immediate issue.
I’d be happy to take a look at implementing this, but I’m a bit
clueless where to begin, as it’s much more general than my previous
attempt. If you (or others) have the time, I’d appreciate any pointers
that’d make it easier to begin.
For instance: I would expect the ‘output’ form to be lowerable,
which would be done in the ‘compile’ branch of a gexp-compiler, but then
it would have to be expanded later in the ‘expand’ branch, which
presents an issue: the third argument to the expander procedure is
already an output. Would we do away with that argument? Somehow fill it
in based on the ‘output’ form (either expressed or implicit)? Let the
‘output’ form, if present, override it?
-bjc
