On Wednesday, May 26th, 2021 at 2:02 PM, Ludovic Courtès <l...@gnu.org> wrote:
> > Could the new syntax accept both variables and specifications, e.g.,
> >
> > (list "glib:bin" foo "bar@2.3")
> >
> > ?
>
> No! I mean, yes it could, but no, I don’t think that’s a good idea.
>
> :-)
>
> In terms of API, I prefer clarity; in this case, I think inputs should
>
> be a list of packages or other “lowerable” objects, rather than a list
>
> of “anything” that could be magically interpreted at run time.
I agree with this, a list of potentially ambiguous "any-type" inputs seems
fraught.
I think there's an opportunity to avoid the need to "fall back" to the status
quo, though. I picture a structure for inputs that has three cases, trivially
decided based on data shape:
- a bare symbol, eg '(tzdata glib)
this is translated to `(("tzdata" ,tzdata) ("glib" ,glib))
works the exact same if the symbol is an =origin=, you get the name of the
symbol quoted followed by the value of the symbol.
- a 2-tuple, eg '(tzdata ("gnome-lib" glib))
when we encounter a 2-tuple, we use the first value as the label and the
second as the value.
so this becomes `(("tzdata" ,tzdata) ("gnome-lib" ,glib))
- a 3-tuple, eg '(tzdata ("glib:bin" glib "bin"))
when we encounter a 3-tuple, we use the first value as the label, second as
the value, and third as the output name.
Following this convention, the inputs for most packages will be a list of bare
symbols, and packages which need custom labels and/or outputs for some inputs
can get them with little effort.
Cheers,
Ryan
