Re: [PATCH RFC 0/4] Getting rid of input labels?

[Ryan Prior <rprior@protonmail.com>]

On Wednesday, May 26th, 2021 at 2:02 PM, Ludovic Courtès <ludo@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