bug#50349: [PATCH] packages: Add 'define-package' syntax.

[Sarah Morgensen <iskarian@mgsn.dev>]

Hi all,

Thanks for your comments.  I'm replying specifically to this message but
these thoughts apply to the issue as a whole.

Maxime Devos <maximedevos@telenet.be> writes:

> Sarah Morgensen schreef op do 02-09-2021 om 21:06 [-0700]:
>> Hello Guix,
>> 
>> This patch adds a shorthand for "(define-public name (package ...))":
>> 
>> (define-package my-favorite-package
>>   (name "my-favorite-package")
>>   ...)
>
> This could be even shorter in the special case that the variable name
> and package name are the same (modulo types):
>
> (define-package "my-favorite-package"
>   (version ...)
>   ...)
>
> 'datum->syntax' and 'string->symbol' can be used to turn "my-favorite-package"
> into an identifier.
>
> A 'define-unexported-package' might be required in some places.

Sure, or perhaps 'define-private-package'.  I think this is pretty rare,
though?  And often in those cases other forms are used which may be
incompatible with the macro, so they'll have to use the original syntax
anyway.  Either way is fine IMO.

There are also about 150 packages which use 'package/inherit'.  Should
we introduce special syntax for them?  What about 'hidden-package'
(about 60 packages)?  (And 11 use both!)

About the only form I can think of that wouldn't break the composability
of these kinds of things is something like

  (define-package* hello (hidden)
    (name "hello")
    ...)

or

  (define-package* hello (hidden inherit-replacements)
    (name "hello")
    ...)

Where 'hidden', 'inherit-replacements', and so on would be procs to
apply (in the same order as compose?) that each transform the package.
Or we could even have them transform the package syntax directly.

But that's even more magic; it would take a fair amount of work, and be
hard to get right.  (How well would it hold up to syntax errors?)

>
> [...]
> This looks nice to me.  IIUC, the define-package is intended to be clearer
> to newcomers, so you might want to ask for feedback on the new syntax on
> help-guix@gnu.org.

Thanks for the suggestion, I definitely will.

With an eye toward newcomers, I think one "gotcha" of the "optional
name" version is inheritance.  If I have

(define-package rust-actix-0.10
  (name "rust-actix")
  ...)

and then I write

(define-package rust-actix-0.20
  (inherit rust-actix-0.10)
  ...)

At best, I would be unsure about whether this package would inherit the
name.  At worst, I would assume the name is inherited, and I would be
wrong.  If I have to write the name, there is no ambiguity.

For the automatic naming (because of gotchas like that), and for
possible extensions discussed above, I think right now I'm tempted to
agree with Ludo's comment when this last came around (thanks to Tobias
for pointing out the conversation)[0]:

ludo@gnu.org (Ludovic Courtès) writes:

> However, I prefer treating packages just like any other Scheme object,
> and to avoid introducing “magic” with macros like this.

I could be convinced with an elegant enough implementation though! ;)

[0] https://lists.gnu.org/archive/html/bug-guix/2013-09/msg00005.html
--
Sarah