From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id drdgA/ZyKGWnzAAA9RJhRA:P1 (envelope-from ) for ; Fri, 13 Oct 2023 00:28:06 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id drdgA/ZyKGWnzAAA9RJhRA (envelope-from ) for ; Fri, 13 Oct 2023 00:28:06 +0200 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 0B7D843ABC for ; Fri, 13 Oct 2023 00:28:05 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fernseed.me header.s=MBO0001 header.b=z9KROZjB; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fernseed.me (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697149686; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Rd78TF+9LxJt81NnGDRmun8vZCVO00xYPCQB/gsAfYw=; b=mGnVq/SGAcVXx0giT/d0bIxGwcVQUNs0bvASuTVwn5t/4AsTXyzeHZyxwwa1AwXBX1+iMy F7jQ/f06pKbV1tZH6jMHHKWiGmcQ4xVi1i/LnMy+LQYdM55Ho3nTa3WyP09L5kU2TMI+F5 s2gdcVdTSjQvmBPwuFd4Qm3NVvptiNXIzRSuEY45j0Jl8rO1gknBlw3uJJnJQjGNVoZyzY UR+hROg9hYogKh9hn+gnY9PEigBNZ8VGlZaN1UVsOcPxgWMEaPsxVJp+T1PoPDP1iRLCTQ F82Fe4Y9n15J2kENpDPbpnaNbqBXfRuO+m1HkP5n3sfz5nn919ueYsm8VgDplA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1697149686; a=rsa-sha256; cv=none; b=gWBcntTyn7XejDDv3fii9Q2xCJ43V3DsTsK4DlRBQlA/AmBixClux4SY+B7If8MtsI3Qwe SwETdMSx2Kq8XLKoUQRQutlY28rSvuzMpf+UoXa6svpyVqqMHh4eshME579eLgmQZoktTv qUszj2nDovcE8+d8hLUBufW3ra+mIGm89Pkgi5+GKtpG6Lt+QazCpKA5EueKsRjlT2osJs 9V+uPNQvDvUv768mmAJj2v5HYvHQabuMbYtDJvFWcucs6DOlwhWXpNKrqwdMKjHcMU50qy s4ttvV5o+legr7ByKbgyn0zOnXTzwV0cD7+k2tD+DRt6bByGbRAMlTIjcZ1+Zw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=fernseed.me header.s=MBO0001 header.b=z9KROZjB; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=fernseed.me (policy=none) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qr49h-0006nr-R7; Thu, 12 Oct 2023 18:27:45 -0400 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 1qr49g-0006nL-2t for guix-patches@gnu.org; Thu, 12 Oct 2023 18:27:44 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qr49c-0007pR-H6 for guix-patches@gnu.org; Thu, 12 Oct 2023 18:27:43 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qr49y-00084A-AJ for guix-patches@gnu.org; Thu, 12 Oct 2023 18:28:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#64620] [PATCH] gnu: home: Add home-emacs-service-type. Resent-From: Kierin Bell Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 12 Oct 2023 22:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64620 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Josselin Poiret , Tobias Geerinckx-Rice , Simon Tournier , paren@disroot.org, Christopher Baines , 64620@debbugs.gnu.org, Andrew Tropin , Ricardo Wurmus , Mathieu Othacehe Received: via spool by 64620-submit@debbugs.gnu.org id=B64620.169714962230925 (code B ref 64620); Thu, 12 Oct 2023 22:28:02 +0000 Received: (at 64620) by debbugs.gnu.org; 12 Oct 2023 22:27:02 +0000 Received: from localhost ([127.0.0.1]:44436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qr48z-00082Y-Tq for submit@debbugs.gnu.org; Thu, 12 Oct 2023 18:27:02 -0400 Received: from mout-y-209.mailbox.org ([91.198.250.237]:60296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qr48u-00082B-FU for 64620@debbugs.gnu.org; Thu, 12 Oct 2023 18:27:00 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-y-209.mailbox.org (Postfix) with ESMTPS id 4S64420Y6Cz9tfD; Fri, 13 Oct 2023 00:26:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fernseed.me; s=MBO0001; t=1697149586; h=from:from: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; bh=Rd78TF+9LxJt81NnGDRmun8vZCVO00xYPCQB/gsAfYw=; b=z9KROZjBbqNKp6bp7sJGYMNyBZpCVnIO4do1bBuOW/06vSzkWnXXTLP7YiAWEmrg7t037+ twNG3ADwFXgWN47C2sZ0fH7ud7Cn4S7G6kyfoFJJxiBQ/8HTogy57p2znTXoARkZ+bZPUH gF4rZZl54I4Q6FqB9vlT6RysR3a+yVn1PYZ53zi3pk90jn/wWxgs3dEkIV8RB/w+oUtsSO bW889lWjfRljnOmJCKrY7G/z5yNEJFbx9YkHkJZNot5xYhZI5Nv6WcBK4nu1ByRFGJy6PZ RwKqHBE6LP6kENUFXb1tgyrZhuXIHwHvowP63/wfR9urKPqc1radxRVTs8G6Uw== From: Kierin Bell In-Reply-To: <87lec9t890.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Wed, 11 Oct 2023 18:48:59 +0200") References: <0173e076aafb6ec389a7ebca5d56b7f4e8a02b6e.1689347338.git.fernseed@fernseed.me> <87lec9t890.fsf@gnu.org> Date: Thu, 12 Oct 2023 18:26:20 -0400 Message-ID: <871qdz4gvn.fsf@fernseed.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: 7.31 X-Migadu-Queue-Id: 0B7D843ABC X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: 7.31 X-TUID: jFlK6eOrDoPC Ludovic Court=C3=A8s writes: > So, here is a short review of the parts I=E2=80=99m most familiar with. > > fernseed@fernseed.me skribis: > > > [...] > >> +(define-module (gnu home services emacs) >> + #:use-module (gnu home services) > > [...] > >> + #:re-export (blank? >> + >> + vertical-space >> + vertical-space? > > Why re-export these things from here? Sounds surprising because we=E2=80= =99re > in a service module. > > IIRC, my rationale was that the `' objects can contain records, e.g., `elisp->sexp' can return them. But users won't normally be manipulating them, so I should probably remove this. > > For clarity/conciseness, you can use #~ and #$ in this code. > Thanks, fixed. > > I think you don=E2=80=99t need to fiddle with the monadic interface. I= =E2=80=99d > suggest removing the type and gexp compiler and instead > defining =E2=80=98elisp-file=E2=80=99 in terms of =E2=80=98computed-file= =E2=80=99. WDYT? > This would prevent people from being able to reference Elisp files in G-expressions, or from writing something like: --8<---------------cut here---------------start------------->8--- (elisp-file "elisp-file-with-elisp-file" (list (elisp (load (unelisp %another-elisp-file))))) --8<---------------cut here---------------end--------------->8--- ...Right? As long as the Emacs home service type offers a better way to load files, which I think it does, I'm OK with losing this capability. >> +(define (record-value rec field) >> + "Return the value of field named FIELD in record REC." >> + ((record-accessor (record-type-descriptor rec) field) rec)) >> + >> +(define-syntax extend-record >> + ;; Extend record ORIGINAL by creating a new copy using CONSTRUCTOR, >> + ;; replacing each field specified by ORIG-FIELD with the evaluation o= f (PROC >> + ;; ORIG-VAL EXT-VALS), where ORIG-VAL is the value of ORIG-FIELD in O= RIGINAL >> + ;; and EXT-VALS is the list of values of EXT-FIELD in EXTENSIONS. >> + (lambda (s) >> + (syntax-case s () >> + ((_ constructor original extensions (proc orig-field ext-field) .= ..) >> + (with-syntax (((field-specs ...) >> + (map >> + (lambda (spec) >> + (syntax-case spec () >> + ((proc orig-field ext-field) >> + #'(orig-field >> + (apply >> + proc >> + (list >> + (record-value original 'orig-field) > > I would advice against accessing record fields by name, with run-time > field name resolution. > > The spirit of records, unlike alists, is that there=E2=80=99s a > statically-defined mapping of fields to their offsets in the struct; > without having access to record accessors, you=E2=80=99re not supposed to= be > able to access the record (I know Guile has =E2=80=98struct-ref=E2=80=99, > =E2=80=98record-accessor=E2=80=99, etc., but these are abstraction-breaki= ng primitives > that should be avoided IMO). > > How could this code be adjusted accordingly? I guess you=E2=80=99re look= ing for > a way to iterate over fields? > >From what I remember, the alternatives are all complicated. I do find `extend-record' to be very useful, especially when services need to extend configuration records that have nested records. It's useful enough that I'd like to see it exported from somewhere, but `(gnu home services emacs)' hardly seems like the place. I propose that we put `extend-record' and a few of the most useful `extend-record-*' procedures --- like `extend-alist-merge' and `extend-record-field-default' (which I rewrote since v1 of the patch because there was a bug) --- into `(guix records)'. There, it could use `lookup-field+wrapper' to manually find the offset like `match-record'. This isn't exactly ideal, as it would still need to then use `struct-ref' or similar, but at least `match-record' does this, too. WDYT? >> +;;; Elisp reader extension. >> +;;; >> + >> +(eval-when (expand load eval) >> + >> + (define (read-elisp-extended port) >> + (read-with-comments port >> + #:blank-line? #f >> + #:elisp? #t >> + #:unelisp-extensions? #t)) >> + >> + (define (read-elisp-expression chr port) >> + `(elisp ,(read-elisp-extended port))) >> + >> + (read-hash-extend #\% read-elisp-expression)) > > I=E2=80=99d lean towards not having a reader extension because they don= =E2=80=99t > compose and it=E2=80=99s easy to end up colliding with another, unrelated > extension. I think it=E2=80=99s okay if people write: > > (elisp =E2=80=A6) > > rather than: > > #%(=E2=80=A6) > > It=E2=80=99s also arguably easier to understand for a newcomer. > I'm OK with losing the reader extension. After some experience, I find that I'd rather use `elisp'. Being able to use semicolons for comments via reader extension is impressive but also weirdly unsettling. Also, anyone who wants to seriously write a lot of Elisp-in-Scheme will want to instead use the `elisp*' macro, which can contain multiple s-exps. And in order to use the reader extension there, you'd need to write something like: (elisp* ;; ... (unelisp #%SEXP-1) (unelisp #%SEXP-2) ;; ... ) >> +++ b/guix/read-print.scm > > This part is the most =E2=80=9Cproblematic=E2=80=9D for me: I=E2=80=99m a= lready dissatisfied > with the current state of things (the pretty-printer in particular is > too complex and hard to work with), and this change brings more > complexity and lacks orthogonality. > > What I=E2=80=99d like to see, ideally, is a clear separation between elisp > concerns and Scheme concerns in the reader and in the pretty printer. > > Probably, a preliminary step (I could look into it) would be to rewrite > the pretty printer based on Wadler=E2=80=99s =E2=80=9Cprettier printer=E2= =80=9D paper and/or > Shinn=E2=80=99s formatting combinators=C2=B9. > > WDYT? > I can honestly say that I'm dreading splitting the `(guix read-print)' changes I've made into multiple commits and annotating them properly. Writing the pretty printer from scratch sounds a lot less confusing and painful at this point. I'm imagining a stripped-down version of the "formatting combinators" from SRFI-159/166 specifically adapted for pulling into service modules to write pretty-printers, not just for Elisp but also for other configuration languages. It's too bad that Guile doesn't have SRFI-159/166 and the requisite "environment monads" and delayed computation from SRFI-165 built-in. My first design question would be: Would this be a suitable application for `(guix monads)' [to create a formatting "environment monad"], or does that entail more trouble than it's worth? I'll work on the unit tests, as well, especially once more progress has been made on the pretty-printer situation. > Thanks, > Ludo=E2=80=99. Thanks, I appreciate the feedback! --=20 Kierin Bell GPG Key: FCF2 5F08 EA4F 2E3D C7C3 0D41 D14A 8CD3 2D97 0B36