From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id AL5oGnO7LmWlbgEA9RJhRA:P1 (envelope-from ) for ; Tue, 17 Oct 2023 18:50:59 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AL5oGnO7LmWlbgEA9RJhRA (envelope-from ) for ; Tue, 17 Oct 2023 18:50:59 +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 B7B5744A7E for ; Tue, 17 Oct 2023 18:50:58 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=gDwywmCM; 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=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697561459; 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: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=kQsORQqC5t7ELxw4Gcd1XLGgIIE1KBApKTbuqNvg+X0=; b=c+567U9t7C9vUEk3t80QVgf6HwfUsDY9aKKp0UfFYd2M/s4ecI0iA/lJ6HakvXFLmrmEEK sLqyxDLBIQkYcYRtIuWqPjUQuxhGPf+65Qa1X2JTu1Ru4t9QYBceEuhvM/ABo324nutLpw jrMquU2y6m8Jnmq4+rOO1zpkd44pNxVOBObQS7LDj7HVpkgv+o/wblX5niCPNE7tAdMMj4 xUK3zNLP+Fl8fxNLF3w4HPRh3Ae+UNfAJfXnbLk+oQEjH8dAHxchT706Sba2WzPHCPUfsF EwKkVo1dzjIDecpbrGYU6zySXBBQWlMeDu9Bwu5wW1/2qIvFD6DuLXvPHDcS3Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20230601 header.b=gDwywmCM; 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=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1697561459; a=rsa-sha256; cv=none; b=YSh5hS3tvPUWnPfn8jwFvHGL4OevUrCrkL4S04qRnlhe878KJINQcIOK0oK1dHptWhWxg5 SKTfpW+kkjC4rBRCs3PInNOn/9VpF8VdKjQ4sEiu1hYjsyW/ZwtaxXJzX4pqrczcgIvLSR BUJp8ZuaopRE4Pa4xE7jOkkcfwJwbP1HrzYm4i+V9q+6+sthiqUsjwO7fIhoz6nMEysMIU sypcad2wPvYCOgFKpR+ezLmgQ6XA+j5w1iZy902rk83ZgELvn3dQDkRrdIHS7WfQqESiwM nxopmsofWlR3GuKn2KcvWEFNJShhPT6QkRVJORSIfyR7ZUWXAruzLYIFZG9j6A== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qsnHD-0006AL-Al; Tue, 17 Oct 2023 12:50:39 -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 1qsnHB-00069k-9e for guix-patches@gnu.org; Tue, 17 Oct 2023 12:50:37 -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 1qsnHB-0006zv-1w for guix-patches@gnu.org; Tue, 17 Oct 2023 12:50:37 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qsnHa-0007UP-DL for guix-patches@gnu.org; Tue, 17 Oct 2023 12:51:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#66562] [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory for snippets. Resent-From: Rostislav Svoboda Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 17 Oct 2023 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66562 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler Cc: 66562@debbugs.gnu.org Received: via spool by 66562-submit@debbugs.gnu.org id=B66562.169756143528750 (code B ref 66562); Tue, 17 Oct 2023 16:51:02 +0000 Received: (at 66562) by debbugs.gnu.org; 17 Oct 2023 16:50:35 +0000 Received: from localhost ([127.0.0.1]:60942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qsnH8-0007Td-NU for submit@debbugs.gnu.org; Tue, 17 Oct 2023 12:50:35 -0400 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:45449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qsnH7-0007TN-0X for 66562@debbugs.gnu.org; Tue, 17 Oct 2023 12:50:33 -0400 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-507b18cf2e1so2879471e87.3 for <66562@debbugs.gnu.org>; Tue, 17 Oct 2023 09:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697561401; x=1698166201; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kQsORQqC5t7ELxw4Gcd1XLGgIIE1KBApKTbuqNvg+X0=; b=gDwywmCMedZLyj3C03lTk1qi5FG7d+SX22exwwMK1bf1lyiSl3w3WCmBHrcQWAXM5G AZAJwUKstwiwcwUZXpUhF1MWAr/7M1upYLEuMd48aJQArM1YDvYcE84Np1CXd3J9lF6t Bg+Eo5gtboZTOghGIE7ZJr8SpQtgz/fcNfrqw9XbmtcpqhFlkaxQUrPR6ooSBObLL9KU DCtTFN5yaXLt+jrkiBSyzlBmhEerL0R1UwhaEOmKoj/K9XlxNoC+Omjc/8Pkc4ZOX57l xjP/gByvIZX2nLDzD642LwYvgeyxkT4cs8ANL3sDspMcAVe45gBnCTT0Dn70YWo0FE6+ pGaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697561401; x=1698166201; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kQsORQqC5t7ELxw4Gcd1XLGgIIE1KBApKTbuqNvg+X0=; b=RtE8DuEK56fGhD6T/bNX9Tm1x4VOAd8aLz2yd0n152vSO83rgtGdD+nwr1dbrCqsoA FFDq/PItOndVk/JlMVIp3xyaAj+qBMXVKsSOpcur2nObGLeFPrKXDfZoMIgBgS7+GVTe p2A6ZczZDP3AmmOKyGCqqCS42+TTZJP8o7Q+/0lPI8cCQ1p+/JqcVKJKBlxVZgrlYpFI RcId6Izp5pyGFAALuQqA/L9KBLMiZRaUyG3ukZXPuHgdmhMFO10zzYG4oxtROJmvoywi 0AGie5RnnlBZ9TjLF+Zcs1P+HleNLJYXIiE73cm5nHO4JsMU/KJlzcfvrn8laHRKNtrM JQHQ== X-Gm-Message-State: AOJu0Yyxz/68pAI4WBPxkThDcNsg9NKBBRi7kG6sdTln3o4IyQ5R5ld+ LeephZqz1dxs94fGqYkfKDsPQcZVsTDF8p2N9TI= X-Google-Smtp-Source: AGHT+IHpwfaOtc5czTGSf+Hh4Xo/9ApOaTGau/6mSx24Wqk+YmaH6bLjdLe1HUXZiDUkgpmW/p0ESj6uX0DwU49ghts= X-Received: by 2002:a05:6512:2202:b0:507:a00a:262b with SMTP id h2-20020a056512220200b00507a00a262bmr2690279lfu.68.1697561400543; Tue, 17 Oct 2023 09:50:00 -0700 (PDT) MIME-Version: 1.0 References: <36c6ef9a672215883a84b8fec5a58a440d32ee11.1697394827.git.liliana.prikler@gmail.com> <17cd7d2255c7e3e1efb1fb83fc4c0cc84c0c127e.camel@gmail.com> In-Reply-To: <17cd7d2255c7e3e1efb1fb83fc4c0cc84c0c127e.camel@gmail.com> From: Rostislav Svoboda Date: Tue, 17 Oct 2023 18:49:23 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 5.86 X-Spam-Score: 5.86 X-Migadu-Queue-Id: B7B5744A7E X-Migadu-Scanner: mx2.migadu.com X-TUID: NE7k6Qvt/KXa Hi Liliana, >> Your patch works (thank you) and I improved it a tiny bit. (See >> attachment.) BTW shouldn't the revision number in the (git-version >> "0.1.0" "1" commit) be increased to "2" in your patch and to "3" in >> mine? > No. It should just be one patch anyway and the change doesn't affect > the source code, but the build recipe. As such, the rebuild is going > to happen either way. > >> DRY in the specification of the relative path of the snippets >> directory. > You can just amend my commit. > >> - (let ((snippets >> - (string-append >> - (elpa-directory (assoc-ref outputs "out")) >> - "/snippets/haskell-mode"))) >> - (mkdir-p snippets) >> - (copy-recursively "snippets/haskell-mode" >> snippets))))))) >> + (let* ((relative-dirpath "snippets/haskell-mode") >> + (installation-dir >> + (string-append (elpa-directory (assoc-ref >> outputs "out")) >> + "/" relative-dirpath))) >> + (mkdir-p installation-dir) >> + (copy-recursively relative-dirpath installation- >> dir))))))) > Now you repeat yourself on relative-dirpath Sure. We have to specify what to copy, and where to copy it. If what and where maintain the same structure, then some repetition is inevitable. > Sometimes explicit is better than implicit, > even if it comes at the cost of typing a constant twice :) A typo in a constant is a runtime error, whereas a typo in a variable name gets caught by the compiler. That's the main rationale behind my patch. (The rest of my email contains just some side remarks.) Cheers, Bost > (which is a very Java name anyway, just five characters shorter than > the original value won't win you Kolmogorov complexity). If it were up to me, I'd use 'src', 'dst'. I find the 'no abbreviations for identifiers' policy excessive. > Plus you're requiring let* instead of let. Having both variants is a language deficiency, in my opinion. Only let should exist, functioning as let* does. This should extend to lambda*, define*, etc. > Btw. don't > ((compose > (lambda (src dst) (mkdir-p src) (copy-recursively dst src)) > (lambda (dir store) (values dir (string-append store "/" dir))) > "snippets/haskell-mode" (elpa-directory (assoc-ref outputs "out"))) > to avoid gratuitous repetition. On the one hand, we face gratuitous repetition; on the other, a snippet like this better expresses compositional transformation between inputs and outputs, which I find to be a way more important that avoiding gratuitous repetition (pun intended). And as a side effect it also simplifies debugging: ((compose ;; (lambda (a b) (format #t "[DBG] 3. a: ~a; b: ~a\n" a b) (values a b)) (lambda (src dst) (mkdir-p src) (copy-recursively src dst)) ;; (lambda (a b) (format #t "[DBG] 2. a: ~a; b: ~a\n" a b) (values a b)) (lambda (dir store) (values dir (string-append store "/" dir))) ;; (lambda (a b) (format #t "[DBG] 1. a: ~a; b: ~a\n" a b) (values a b)) ) "snippets/haskell-mode" (elpa-directory (assoc-ref outputs "out"))) And if you insist, the gratuitous repetition could, in theory, be avoided: ((compose copy-recursively (juxt mkdir-p (partial string-append (elpa-directory (assoc-ref outputs "out")) "/"))) "snippets/haskell-mode") Only if partial and juxt would exist... and here you go ;-) (define (partial fun . args) "Partial function application." (lambda x (apply fun (append args x)))) (define (juxt . fns) "Naive implementation. Inspired by Clojure's juxt. ((juxt a b c) x) => (list (a x) (b x) (c x))" (lambda args (map (lambda (fn) (apply fn args)) fns))) Here yet another pattern appears, the map-reduce. Also the juxt function just screams for "let's call the mkdir-p and (partial string-append ...) in parallel". > Btw. don't (compose ...) Quite the contrary, I think we should do more of (compose ...), however functional composition is hard-to-impossible if e.g.: - essential higher order functions like juxt and partial are not available. - mkdir-p and copy-recursively from the (guix build utils) aren't monadic and mkdir-p returns #t instead of a path-string and copy-recursively returns: scheme@(guile-user)> ,use (guix build utils) scheme@(guile-user)> (copy-recursively "/tmp/f1.txt" "/tmp/f2.txt") `/tmp/foo.txt' -> `/tmp/fox.txt' eeeh... what exactly is the return value of copy-recursively? Hmm. - copy-recursively, although naturally a reducer (i.e. a member of the fold-family, think of 'a list of things goes into a container') is not implemented as such. Hmm, disappointing... although a <...>-fold is used in its implementation. Double hmm. - in general, the built-in compose function can't be called with zero arguments. For that purpose I cobbled myself: (define (comp . fns) "Like `compose'. Can be called with zero arguments. I.e. (thunk? comp) => #t Works also for functions returning and accepting multiple values." (lambda args (if (null? fns) (apply values args) (let [(proc (car fns)) (rest (cdr fns))] (if (null? rest) (apply proc args) (let ((g (apply comp rest))) (call-with-values (lambda () (apply g args)) proc))))))) And finally, in the (guix build utils) there's the install-file which works with single files. What about adding its recursive version: (define* (install-recursively source destination #:key (log (current-output-port)) (follow-symlinks? #f) (copy-file copy-file) keep-mtime? keep-permissions?) "Recursive version of install-file." (mkdir-p destination) (copy-recursively source (string-append destination "/" (basename destination)) #:log log #:follow-symlinks? follow-symlinks? #:copy-file copy-file #:keep-mtime? keep-mtime? #:keep-permissions? keep-permissions?))