Ludovic Courtès <[email protected]> writes:
> Hi, > > Ricardo Wurmus <[email protected]> skribis: > >>>From 40c1208cbe9cbfa58ee385ef6ee06b775d309753 Mon Sep 17 00:00:00 2001 >> From: Ricardo Wurmus <[email protected]> >> 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! I finally did give it a try. I’m re-exporting “delete” and I don’t get any warnings. I pushed this with commit a247f5c7537df7e0c09051ba22d5c95eb08f48b9. Thank you for the review and your comments! -- Ricardo
