From: "Ludovic Courtès" <ludo@gnu.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: 41140@debbugs.gnu.org
Subject: bug#41140: “guix system” suggests wrong module import when using “remove”
Date: Mon, 11 May 2020 22:22:36 +0200 [thread overview]
Message-ID: <87lflyfchf.fsf@gnu.org> (raw)
In-Reply-To: <877dxj327c.fsf@elephly.net> (Ricardo Wurmus's message of "Sun, 10 May 2020 23:33:11 +0200")
Hi,
Ricardo Wurmus <rekado@elephly.net> skribis:
>>From 40c1208cbe9cbfa58ee385ef6ee06b775d309753 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus <rekado@elephly.net>
> Date: Sun, 10 May 2020 23:29:38 +0200
> Subject: [PATCH] services: Support DELETE in MODIFY-SERVICES macro.
>
> * gnu/services.scm (%modify-service): Add clause for DELETE syntax.
> (modify-services): Use FILTER-MAP; adjust docstring.
> * doc/guix.texi (System Services): Mention alternative syntax.
> (X Window): Use MODIFY-SERVICES syntax.
I like it!
> - #:use-module (srfi srfi-1)
> + #:use-module ((srfi srfi-1) #:hide (delete))
> #:use-module (srfi srfi-9)
> #:use-module (srfi srfi-9 gnu)
> #:use-module (srfi srfi-26)
> @@ -272,7 +273,11 @@ singleton service type NAME, of which the returned service is an instance."
> (service type value)))
>
> (define-syntax %modify-service
> - (syntax-rules (=>)
> + (syntax-rules (=> delete)
> + ((_ svc (delete kind) clauses ...)
> + (if (eq? (service-kind svc) kind)
> + #f
> + (%modify-service svc clauses ...)))
Best practice suggests that ‘delete’ should be bound (info "(guile)
Syntax Rules"):
--8<---------------cut here---------------start------------->8---
Although literals can be unbound, usually they are bound to allow
them to be imported, exported, and renamed. *Note Modules::, for more
information on imports and exports. In Guile there are a few standard
auxiliary syntax definitions, as specified by R6RS and R7RS:
--8<---------------cut here---------------end--------------->8---
Now, if we export a new ‘delete’ binding from here, it’ll annoy
everyone. So perhaps we can keep the srfi-1 ‘delete’ and re-export it,
as done in (guix build utils)… though that situation is also annoying
because we get warnings saying that it collides with core ‘delete’.
Dunno, give it a try!
Ludo’.
next prev parent reply other threads:[~2020-05-11 20:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 22:00 bug#41140: “guix system” suggests wrong module import when using “remove” Ricardo Wurmus
2020-05-09 7:30 ` Danny Milosavljevic
2020-05-10 21:33 ` Ricardo Wurmus
2020-05-11 20:22 ` Ludovic Courtès [this message]
2021-04-12 16:21 ` Ricardo Wurmus
2020-05-11 20:23 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lflyfchf.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=41140@debbugs.gnu.org \
--cc=rekado@elephly.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).