From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id KCFxCQOXY2XgSAAA9RJhRA:P1 (envelope-from ) for ; Sun, 26 Nov 2023 20:05:39 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id KCFxCQOXY2XgSAAA9RJhRA (envelope-from ) for ; Sun, 26 Nov 2023 20:05:39 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 94875104E3 for ; Sun, 26 Nov 2023 20:05:38 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=mvusPRqA; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1701025539; a=rsa-sha256; cv=none; b=JNd9E/x91MWYmK5S/wHuO8mpcZweE9Fnx5DccqfLX1HP+FZ/2SpLpwMYmsxg1h0oYftTtZ BBOqUbE6rQKDs/6+8ki9SD7UPCP47GuwFyn5a8HEvq/amrvny3GNLp026HOcu9smG5M/Nr V9YHH5x6u1HBAmID+rvrefaBPnXuH6EWA2UFhl99h3USvBwJWXcM6NN3gWBbI4Uhze2oN3 iqFT1cV3b2WZacO+40Gp9q3QBMne0278ELMmgpyHQfCMMuJWJythl1Ppd6JtvJ/R8jeB8t WYQfY5kmqT1iwVWrZbQoic5315qbjFKu8MxLdgj4sYe79UxZwHhsTfB/TYUApw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=mvusPRqA; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1701025539; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=PTVuEJzpxV9hQAtiW0t4Anlip9NyhfNUgMsJYio4xlU=; b=Bpub6yWUyhadA2uxzHZ2tGeJPRxVOStymFVmEFGv5KOgj6MeN1msaTBRcQ/Y9q3ezysm3y 5tpT22VGtDGkbCLJXzYUOv2EwMlbMoTPsSBZNTAs9kiEnYpPFXD3YpGPBwfpBAzZnrsEA/ anztyc2hS2Un8+9VtUbRpKbnErHj/Qr6fZukb2ZTOcOTi6L7B+S1LEFbJ+4qQ+2fTwCVpa IGx6ZGeXcM48eDxRMN4Cw/Gz18p2Gm2Y+koEQ+3pR8BhHS51IPVxxZ/nhaus7Yke+WqA5k ZAqicYyNWXyxi9YJw5eUW7GxrZuZuD5BxfKBXGbUc+sCHzkOv/xxbggrhxkWTw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7KRH-0006Ml-QD; Sun, 26 Nov 2023 14:05:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r77oP-0002WD-Ok for guix-devel@gnu.org; Sun, 26 Nov 2023 00:36:09 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r77oM-0002Gr-8a for guix-devel@gnu.org; Sun, 26 Nov 2023 00:36:09 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7E9CB240101 for ; Sun, 26 Nov 2023 06:36:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1700976961; bh=sYqxXPlyx6QNL7OfzGC5iq/Eit3O3BGXrm4NLviCLI4=; h=Message-ID:Date:MIME-Version:Subject:To:From: Content-Transfer-Encoding:From; b=mvusPRqAbu/gfiUs7rev2f923jwVUsH1hSNgvJLocfw/sYjFgbRTR2Hc9AMxoXrBH 2zgLT8j4ZyBtTCb2af07DE2i+0cN1b8zd+G3hOkcYMliYcVSIricaD+F3RvmJ5hcVd 17oxwEWWxy+e4FfGtElB8aQU0NJHg+V34Tus3/3mL9zZIHZCAyk3kpzpvdZt0GhrrL H9IQZ9WSdHCw+3yacK1Er69bIh4Xfj5DFRyvj+VubVgBOY9wGCm6NBLbtyL+suyyYC Olzf01u57vpGKQsjXFBDN1+1HkTaloLVdoP6bFyczcVCkpYIFUKwYxonGZAR3daU5D QdlGQt0+PcI4g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SdHWP1LVHz6tvJ for ; Sun, 26 Nov 2023 06:36:01 +0100 (CET) Message-ID: <2da427d0-7f7c-f226-8c54-20ad669956aa@posteo.net> Date: Sun, 26 Nov 2023 05:36:00 +0000 MIME-Version: 1.0 Subject: Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Content-Language: en-US To: guix-devel@gnu.org References: <87wn377rst.fsf@rdklein.fr> <877cm6reum.fsf@rdklein.fr> <52c2337b277721108e5e7cdd6ea32e37e3c20628.camel@gmail.com> From: Michal Atlas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=185.67.36.66; envelope-from=michal_atlas+gnu@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 26 Nov 2023 14:05:06 -0500 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.83 X-Spam-Score: -9.83 X-Migadu-Queue-Id: 94875104E3 X-TUID: +cvPqKECUF6g Hello guix, I'll chime in because I've been playing around with this kind of thing in my channel [1] for a bit now and perhaps some of the ideas will be deemed useful. > (service+ OS SERVICE [CONF]) > (service- OS SERVICE) > (modify-service OS SERVICE UPDATE) I found that defining a functional API like this is about as convenient as the original version, more examples: [2]. Another small change I tried was to not have -> be a macro but rather a simple fold. I took what the dot-macro form expands to and made it a curried function called services (but remove and modify could be equivalently defined), which takes a service and then returns a lambda that takes an OS and modifies it just as the beaver-labs macros do with that extra service. (define ((services . new) os)   (operating-system     (inherit os)     (user-services       (append new (operating-system-user-services os))))) (define (-> system . services)   (fold (cut <> <>) system services)) (-> os (services (service openssh-service-type)) ...) ; yields os with added openssh ((services (service openssh-service-type)) os) ; equivalent The one macro that is indispensable for terse configurations is still some sort of service+ (I use &s as the name), which appends -service-type, surrounds the body in a -configuration [3], and in my case calls `services` on it for good measure to get the os modifying lambda straight from the service+ clause. (-> os   (&s openssh)   (&s guix-publish     (advertise? #t))   ...) This ends up save for 2 extra characters being syntactically almost identical to the original version, just passes around lambdas instead of getting manipulated by nested macros. Them being functions they're now easier to work with with in more traditional Scheme ways, for example compose works, and we can wrap them in other functions that for example apply them only in some circumstances. Or combine transformations into new ones. The definitions for which end up being remarkably short and generalizable. (-> os   (compose (os/hostname "the-dam.org") (&s gpm)) ; freely composable with other functions of the same sort   (%services-with-arguments ...) ; indifferent to being composed on the spot even in the middle of threading   (if-host "hydra" (&s openssh)) ; only adds openssh if the host is named hydra, simple function            ; since the second argument is just a function that may or may not be applied by the new lambda   ((mapped-file-systems ...)     ...))) ; not threading by macro allows more complex structures without confusion Then again none of this has had proper field testing, the fact that it has less gotchas is just a personal opinion. Cheers, and all the best [1]: https://git.sr.ht/~michal_atlas/guix-channel/tree/a31b68b46da60002383e2793eba88b99fc5c2382/item/atlas/combinators.scm (modified from the original beaver-labs version). [2]: https://git.sr.ht/~michal_atlas/dotfiles/tree/8c78f53139ae176ff0a4cab82ad0fb64bce6989b/item/atlas/config/system/services.scm#L56 [3]: https://git.sr.ht/~michal_atlas/guix-channel/tree/master/item/atlas/utils/services.scm#L53