From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id wBdXK64FZWV/BwAAG6o9tA:P1 (envelope-from ) for ; Mon, 27 Nov 2023 22:10:06 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id wBdXK64FZWV/BwAAG6o9tA (envelope-from ) for ; Mon, 27 Nov 2023 22:10:06 +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 ACB171582C for ; Mon, 27 Nov 2023 22:10:05 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=k1l7LZak; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1701119406; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=XM8V7mLcMocaKyLIQaUi34w2g4vSbQyWgZ8Nqu7W//U=; b=fj28kLDQqBIUyP+RO9QKG97NEvxwf7orrsn6HhMKlfGs5WlsS0R/dDL+b9LZoGb/tKmdR5 zuJsEcBRsvGpEnNRvhFg0Ff0XVUx3AjlDfkxAh6sAHPNLHU9QtkjlyNsbwHA2GkE5DZTQ6 Px4sj3IWtaiP7CAL0ZuLdCNEzJwJFZZ8xFmIHtqKYv6+c6klPZ5m6Ht0LeCZrU9lb+saHj 60lFAA8i0Ug+XQiUAPNW2uCPXHesDx2fZL+J8ajf351pcSP6/2NuFe0wpCWnL1CnE5OGPV PiagEZ5XZ0HzrzDxZ11Uy/ydtClh/J2mOYJSbm6nNYe2D+drt6ayGDCBT2P2HA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=k1l7LZak; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1701119406; a=rsa-sha256; cv=none; b=XxYRycyIno31wPSvLZGgXm6N1cU0rjxdwRgoQHjzzepJpk/WAtCJzmBa7XcwNeXM61sShZ /qFdXKQmhr2eHzlakNQS4dRsdWi7c2yOI36Bw9F6WP1rYco44D+HLRrhy8UXN+b8PWRZzT UyiE3Q5LXr1UvajZ+GgRZwTBafL1EbFX2VxTZsrd5/mPR6x61AF5UFhVVJkfGxCj7RM/TY qPFKhkMwE9og0x1TE7iFg6L0acS/mNZbjOuUOzyDffdCjkZcER8+aertaOqi6GUy7Ei+3s zf3RS8gBDp7hDuoZtAiswJ7mLbquIvtrteVPQ/bIXm07QIblJQa2h1P9oyNaSQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r7ir3-00080u-Gy; Mon, 27 Nov 2023 16:09:21 -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 1r7ir1-00080h-AZ for guix-devel@gnu.org; Mon, 27 Nov 2023 16:09:19 -0500 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r7iqy-0003X3-Ja; Mon, 27 Nov 2023 16:09:18 -0500 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50babce6ff6so2944061e87.3; Mon, 27 Nov 2023 13:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701119352; x=1701724152; darn=gnu.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=XM8V7mLcMocaKyLIQaUi34w2g4vSbQyWgZ8Nqu7W//U=; b=k1l7LZakbjmm80VVeW8mIw7WbJQd8VJDa3EbUDP1wC0kYPWAmaeAorYtZnp3gCz70Q W2H1zOEQLNZ7gC4RMDA1K39TbCxGUUJaKWUHGWj/44n94rtv5po8+KLc7DWsvtPu1EnN tXwhYw7pO/oAmp9QJMmP9gXCdNLnMO7bn1ZWH/vbVbiF4eIiN+uR+hdJTEbX9coPGXL6 xO3n12v4yNFGb0bWbVNz/Spbh5MdxXxvjVphakT1q8XDjY1fdeDgy5xpLKDt9DwEo0Bx /QRDEl3Va88/pgeTwsQSTxHIVBoU8BijmekIIHzpseIyIFdeoym2RxZlu0LpfqO8ez6h yAKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701119352; x=1701724152; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XM8V7mLcMocaKyLIQaUi34w2g4vSbQyWgZ8Nqu7W//U=; b=pt5WUjXCGmWodevYRRDtNHbPzN8H+X1JgeOChIcUp9vTUluH9v+YBYnajxOTwvHZg/ zpipmGLmam0IseBtRWJ5X37zyvKzFuoX64LrlKhj8VQ8ZnKe0WZ1h1roEUQsmIsSFoEm K8leMPPHQtn7MlzZIBxCrTwzMdQqT2rKkPyie5OwdByTzIveDk5mHBdWqJ9oTsSnaPx7 1mua6CyNJzc1GCwX0U5HwDb9XdP9M8W0jed9VA+CVjA2Lc8IwqvBJ/MsJmupQQl+I9uj 5Mn4RyntmkRCg5wOztng+lL7RN47dWzcMLhLn1dL0/fQfUbH+U9eNvs5OyL/ZPAHs6DA 15aA== X-Gm-Message-State: AOJu0Ywn8mnL1/9M5E0bBCTxKSDw+Ygto9QvL/vLabGhKqU6Pl7Zt/wz vaqq917fnekdmzUx4O/WJtAOxoYlr3U= X-Google-Smtp-Source: AGHT+IEcPig03msnlIHy6Dni7xk29DU/77LS8+SB1FqA5E4GkG2QHJs/fpIzzYOXiM/UnPqxUUqjzg== X-Received: by 2002:a2e:848b:0:b0:2c8:81a2:344b with SMTP id b11-20020a2e848b000000b002c881a2344bmr8529485ljh.44.1701119351940; Mon, 27 Nov 2023 13:09:11 -0800 (PST) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id z15-20020a05600c220f00b003fe1fe56202sm14831586wml.33.2023.11.27.13.09.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Nov 2023 13:09:11 -0800 (PST) Message-ID: Subject: Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) From: Liliana Marie Prikler To: Edouard Klein Cc: Attila Lendvai , guix-devel@gnu.org, Ludovic =?ISO-8859-1?Q?Court=E8s?= , Josselin Poiret Date: Mon, 27 Nov 2023 22:09:09 +0100 In-Reply-To: <87v89op6f2.fsf@rdklein.fr> References: <87wn377rst.fsf@rdklein.fr> <877cm6reum.fsf@rdklein.fr> <52c2337b277721108e5e7cdd6ea32e37e3c20628.camel@gmail.com> <8734wsqwrh.fsf@rdklein.fr> <33976deaf13ce785edefa6ac1b3610054dd4a031.camel@gmail.com> <87v89op6f2.fsf@rdklein.fr> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 Received-SPF: pass client-ip=2a00:1450:4864:20::135; envelope-from=liliana.prikler@gmail.com; helo=mail-lf1-x135.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: ACB171582C X-Spam-Score: -9.44 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -9.44 X-TUID: ZZ4KHbrTYW2M Am Sonntag, dem 26.11.2023 um 21:46 +0100 schrieb Edouard Klein: >=20 > Liliana Marie Prikler writes: > > > =C2=A0=C2=A0=C2=A0 (instantiate nginx) > > I do wish you spelled out service.=C2=A0 Also, instantiate takes as muc= h > > characters to type as add-service. > >=20 >=20 > Done, see below. I was worried about the paronymy between add-service > and add-services which already exists. I defer to you and your > experience on this, naming things is hard. That's not that much of a deal in scheme, see let and let* for example. > > > To see the value of this syntactic sugar, try to replicate this > > > MWE > > > with the standard syntax. It's not horrendous, but it *is* off- > > > putting to many newcomers to git, whereas this sugary piece is > > > more > > > readable for them (sample size of 1, p=3D0.00000005). > > Well, that'd be > > ... >=20 > I tried: >=20 > (let ((base (minimal-ovh "osef"))) > =C2=A0 (operating-system > =C2=A0=C2=A0=C2=A0 (inherit base) > =C2=A0=C2=A0=C2=A0 (services > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (cons* > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (service nginx-service-type) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (service mumble-server-service-type > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (mumble-server-configuration > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (welcome-text "couocu") > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (port 64738))) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (service openssh-service-type > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (openssh-configuration > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (password-authentication? #f) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (allow-empty-passwords? #t) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (authorized-keys `(("alice" ,(local-file > "/home/edouard/.ssh/id_rsa.pub")))))) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (operating-system-user-services base= ))))) >=20 >=20 > I admit that this is as readable as the sweet version, but: >=20 > - Openssh is already defined in=C2=A0 (minimal-ovh "osef"), so the build > =C2=A0 fails with: 'guix system: error: service 'ssh-daemon' provided mor= e > =C2=A0 than once' > - you forgot=C2=A0the removal of guix-service, which admitedly is not use= d > much in practice > =C2=A0 anyway Nice catch. > The problem with those two is that they break the nice structure of > just adding services, and now one has to first remove an element from > (operating-system-user-services base), then edit one of the element > of the resulting list, then add to elements to it. It is probably > possible to write it in a readable way, maybe less so than the sweet > version, but not so much as to justify adding the new macros to guix. Fair enough, but you could still implement that as an (extended) modify-services. We haven't reached the level of complexity where we'd touch multiple fields, which is when operating-system really becomes a pain to work with. (The ssh-user from beaverlabs is one such example, that IIRC is also used extensively on the-dam.) > However the readability is not the main selling point, the > writeability is. Please do not discount how hard it is to write that > kind of stuff when scheme's not your main language. It is possible > people here forgot how hard this is for beginners, especially those > like me whose brain is deformed from years using algol-derived > syntaxes. >=20 > I think we are losing a lot of mindshare because of the hard step of > learning both guile and guix, and the kind of syntactic sugar I > suggest may help bridge the gap long enough for newcomers to ease > into the syntax, after they get a taste of guix' capabilities. Fair point, and I'm not really opposed to making things more readable/writable. The problem comes with groking the additional syntax. It is not something the manuals would prepare you for and probably also encounters weird corner cases like services using something else than SERVICE-configuration for its configuration data. > Another experiment: with the sweet syntax, you can easily extend > services, without having to define a -record-type, etc. Just define a > function. I can write more at length about that if you want. That's again just simple-service doing its job tho :) In essence, what I'm trying to get here is something that'd let us implement the more complicated part of OS config fiddling with few lines of code. I think hyper-focusing on syntax to make services "nicer" might be the wrong approach here: You could greatly reduce the complexity by making them procedures instead of syntax and still keep most of the configuration readable to a great extent. Maybe we should start with making modify-services more powerful to also cover the "adding services" case: modify-inputs already does that, so it's weird that modify-services doesn't. We should also think on how to best wrap this in a lambda then; defining a new syntax for most operations doesn't seem all that useful and scalable to me. Cheers >=20