GNU bug report logs - #66562
[PATCH] gnu: emacs-haskell-snippets: Fix haskell-snippets-dir value.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66562 in the body.
You can then email your comments to 66562 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
To: guix-patches <at> gnu.org
Cc: Rostislav Svoboda <Rostislav.Svoboda <at> gmail.com>
Subject: [PATCH] gnu: emacs-haskell-snippets: Fix haskell-snippets-dir value.
Date: Sun, 15 Oct 2023 17:17:30 +0200

* gnu/packages/emacs-xyz.scm (emacs-haskell-snippets): Fix
haskell-snippets-dir value

The value of haskell-snippets-dir was:
  /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/haskell-snippets-*/
It needs to be:
  /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/

The error was (abbreviated):
No such file or directory, /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/haskell-snippets-*/snippets
---
 gnu/packages/emacs-xyz.scm | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index bb8c25f9b5..8bb0d6d43a 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -35545,6 +35545,12 @@ (define-public emacs-haskell-snippets
        (list
         #:phases
         #~(modify-phases %standard-phases
+            (add-after 'unpack 'patch-haskell-snippets-dir
+              (lambda* (#:key outputs #:allow-other-keys)
+                (emacs-substitute-sexps "haskell-snippets.el"
+                  ("setq haskell-snippets-dir"
+                   '(file-name-parent-directory
+                     (file-name-directory load-file-name))))))
             (add-after 'install 'install-snippets
               (lambda _
                 (let ((snippets

base-commit: a0d2ecde943bd1854ddbb7c0cad35a1fc64dc5ab
-- 
2.41.0

Message #8 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>, 66562 <at> debbugs.gnu.org
Cc: Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#66562] [PATCH] gnu: emacs-haskell-snippets: Fix
 haskell-snippets-dir value.
Date: Sun, 15 Oct 2023 18:01:41 +0200

Am Sonntag, dem 15.10.2023 um 17:17 +0200 schrieb Rostislav Svoboda:
> * gnu/packages/emacs-xyz.scm (emacs-haskell-snippets): Fix
> haskell-snippets-dir value
> 
> The value of haskell-snippets-dir was:
>   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-
> lisp/haskell-snippets-*/
> It needs to be:
>   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/
> 
> The error was (abbreviated):
> No such file or directory, /gnu/store/*-emacs-haskell-snippets-
> */share/emacs/site-lisp/haskell-snippets-*/snippets
Explanations go above the ChangeLog.
> ---
>  gnu/packages/emacs-xyz.scm | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index bb8c25f9b5..8bb0d6d43a 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -35545,6 +35545,12 @@ (define-public emacs-haskell-snippets
>         (list
>          #:phases
>          #~(modify-phases %standard-phases
> +            (add-after 'unpack 'patch-haskell-snippets-dir
> +              (lambda* (#:key outputs #:allow-other-keys)
> +                (emacs-substitute-sexps "haskell-snippets.el"
> +                  ("setq haskell-snippets-dir"
> +                   '(file-name-parent-directory
> +                     (file-name-directory load-file-name))))))
There is actually a substitute-sexps specialization for variables. 
Perhaps use that instead?

Cheers

Message #11 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org, Katherine Cox-Buday <cox.katherine.e+guix <at> gmail.com>,
 Andrew Tropin <andrew <at> trop.in>
Subject: Re: [bug#66562] [PATCH] gnu: emacs-haskell-snippets: Fix
 haskell-snippets-dir value.
Date: Sun, 15 Oct 2023 19:21:29 +0200

[Message part 1 (text/plain, inline)]

> > +                (emacs-substitute-sexps "haskell-snippets.el"
> > +                  ("setq haskell-snippets-dir"
> > +                   '(file-name-parent-directory
> > +                     (file-name-directory load-file-name))))))
> There is actually a substitute-sexps specialization for variables.
> Perhaps use that instead?

The emacs-substitute-variables doesn't work since haskell-snippets-dir
is defined using setq, not defcustom, hence I used the
emacs-substitute-sexps.

> > * gnu/packages/emacs-xyz.scm (emacs-haskell-snippets): Fix
> > haskell-snippets-dir value
> >
> > The value of haskell-snippets-dir was:
> >   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-
> > lisp/haskell-snippets-*/
> > It needs to be:
> >   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/
> >
> > The error was (abbreviated):
> > No such file or directory, /gnu/store/*-emacs-haskell-snippets-
> > */share/emacs/site-lisp/haskell-snippets-*/snippets
>
> Explanations go above the ChangeLog.

Ok, I changed that. See the patch in the attachment.

Cheers

[0001-gnu-emacs-haskell-snippets-Fix-haskell-snippets-dir-.patch (text/x-patch, attachment)]

Message #14 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: 66562 <at> debbugs.gnu.org
Cc: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
Subject: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory for
 snippets.
Date: Sun, 15 Oct 2023 20:25:46 +0200

This package instructs Yasnippet to look for snippets relative to its own
path.  However, it installs the snippets directly to site-lisp, which as of
79cfe30f3eb10bd3dbf7aa0f6e873c945d7d0ea5 is one directory above that.  Use the
elpa-directory procedure introduced in that commit to rectify this mistake.

* gnu/packages/emacs-xyz.scm (emacs-haskell-snippets)[#:phases]
<install-snippets>: Use elpa-directory.

Fixes: 66562
---
Hi Rostislav,

Am Sonntag, dem 15.10.2023 um 17:17 +0200 schrieb Rostislav Svoboda:
> * gnu/packages/emacs-xyz.scm (emacs-haskell-snippets): Fix
> haskell-snippets-dir value
> 
> The value of haskell-snippets-dir was:
>   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/haskell-snippets-*/
> It needs to be:
>   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/
Actually, emacs-haskell-snippets is doing something wrong when installing files
directy to site-lisp instead of any other directory.  Here's an attempt to fix
that.

Cheers

 gnu/packages/emacs-xyz.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index bb8c25f9b5..7f55febfbb 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -35546,10 +35546,11 @@ (define-public emacs-haskell-snippets
         #:phases
         #~(modify-phases %standard-phases
             (add-after 'install 'install-snippets
-              (lambda _
+              (lambda* (#:key outputs #:allow-other-keys)
                 (let ((snippets
                        (string-append
-                        #$output "/share/emacs/site-lisp/snippets/haskell-mode")))
+                        (elpa-directory (assoc-ref outputs "out"))
+                        "/snippets/haskell-mode")))
                   (mkdir-p snippets)
                   (copy-recursively "snippets/haskell-mode" snippets)))))))
       (propagated-inputs

base-commit: ef026e68fe58ed3be216c76f7c5f008893ed3095
-- 
2.41.0

Message #17 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory for
 snippets.
Date: Mon, 16 Oct 2023 12:57:35 +0200

[Message part 1 (text/plain, inline)]

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?

Cheers

Le dim. 15 oct. 2023 à 20:36, Liliana Marie Prikler
<liliana.prikler <at> gmail.com> a écrit :
>
> This package instructs Yasnippet to look for snippets relative to its own
> path.  However, it installs the snippets directly to site-lisp, which as of
> 79cfe30f3eb10bd3dbf7aa0f6e873c945d7d0ea5 is one directory above that.  Use the
> elpa-directory procedure introduced in that commit to rectify this mistake.
>
> * gnu/packages/emacs-xyz.scm (emacs-haskell-snippets)[#:phases]
> <install-snippets>: Use elpa-directory.
>
> Fixes: 66562
> ---
> Hi Rostislav,
>
> Am Sonntag, dem 15.10.2023 um 17:17 +0200 schrieb Rostislav Svoboda:
> > * gnu/packages/emacs-xyz.scm (emacs-haskell-snippets): Fix
> > haskell-snippets-dir value
> >
> > The value of haskell-snippets-dir was:
> >   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/haskell-snippets-*/
> > It needs to be:
> >   /gnu/store/*-emacs-haskell-snippets-*/share/emacs/site-lisp/
> Actually, emacs-haskell-snippets is doing something wrong when installing files
> directy to site-lisp instead of any other directory.  Here's an attempt to fix
> that.
>
> Cheers
>
>  gnu/packages/emacs-xyz.scm | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index bb8c25f9b5..7f55febfbb 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -35546,10 +35546,11 @@ (define-public emacs-haskell-snippets
>          #:phases
>          #~(modify-phases %standard-phases
>              (add-after 'install 'install-snippets
> -              (lambda _
> +              (lambda* (#:key outputs #:allow-other-keys)
>                  (let ((snippets
>                         (string-append
> -                        #$output "/share/emacs/site-lisp/snippets/haskell-mode")))
> +                        (elpa-directory (assoc-ref outputs "out"))
> +                        "/snippets/haskell-mode")))
>                    (mkdir-p snippets)
>                    (copy-recursively "snippets/haskell-mode" snippets)))))))
>        (propagated-inputs
>
> base-commit: ef026e68fe58ed3be216c76f7c5f008893ed3095
> --
> 2.41.0
>

[0001-gnu-emacs-haskell-snippets-Improve-snippets-installa.patch (application/x-patch, attachment)]

Message #20 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory
 for snippets.
Date: Mon, 16 Oct 2023 18:57:56 +0200

Am Montag, dem 16.10.2023 um 12:57 +0200 schrieb Rostislav Svoboda:
> 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 (which is a very Java name
anyway, just five characters shorter than the original value won't win
you Kolmogorov complexity).  Plus you're requiring let* instead of let.

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.

Sometimes explicit is better than implicit, even if it comes at the
cost of typing a constant twice :)

Cheers

Message #23 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory for
 snippets.
Date: Tue, 17 Oct 2023 18:49:23 +0200

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?))

Message #26 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory
 for snippets.
Date: Tue, 17 Oct 2023 19:29:20 +0200

Hi, Rostislav

Am Dienstag, dem 17.10.2023 um 18:49 +0200 schrieb Rostislav Svoboda:
> […]
> > 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.
Only let should exist, functioning as let does.  let* is sugar on top.
(Not serious about this, there are reasons to have let*, but there are
also reasons it's not the default behaviour.)

> > 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")))
If you need to warp your head around through three debug statements,
I'm not convinced you're improving the overall code all that much.

> 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".
You can do all that, but it does go against the KISS principle :)

> > 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.
We have partial.  We call it cut.  It's part of SRFI-26.
It even simplifies the definition of juxt: 
(lambda args (map (cut apply <> args) fns))
Anyhow, we quite often don't use it because we'd have to add it to
#:modules and the benefit over raw lambdas is often negligible.

> - 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.
It returns *unspecified*.  Yes, most of this stuff is indeed not
monadic.  Scheme is not purely functional, so side effects are allowed
:)

> - 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.
There is a cost to constructing the return value of a fold.  I
personally can do without creating lists that no one will end up
inspecting anyway.

> - 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)))))))
I'd argue that compose without procedures is quite meaningless, but
maybe I'm thinking too hard.

> 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?))
There'd be no point in having copy-recursively then.  For a more
complete build system that already takes care of all that without
having you fiddling with juxt, partial, etc., just take copy-build-
system.  Not that it's needed here, mind you.

Cheers

Message #29 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory for
 snippets.
Date: Wed, 18 Oct 2023 10:54:53 +0200

Hi Liliana,

I think we're digressing and since our discussion is mostly about
opinions I'd prefer to discontinue it. Except for one rather important
point:

> > - in general, the built-in compose function can't be called with zero
> > arguments. For that purpose I cobbled myself:
...
> I'd argue that compose without procedures is quite meaningless, but
> maybe I'm thinking too hard.

Food for thought:

in Emacs Lisp:
*** Welcome to IELM ***  Type (describe-mode) or press C-h m for help.
ELISP> (-compose)
#<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_131>

In Racket:
Welcome to Racket v8.10 [cs].
> (compose)
#<procedure:values>

Clojure 1.11.1
user=> (comp)
#object[clojure.core$identity 0x610db97e "clojure.core$identity <at> 610db97e"]

Cheers

Message #32 received at 66562 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
Cc: 66562 <at> debbugs.gnu.org
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory
 for snippets.
Date: Wed, 18 Oct 2023 23:58:34 +0200

Am Mittwoch, dem 18.10.2023 um 10:54 +0200 schrieb Rostislav Svoboda:
> Hi Liliana,
> 
> I think we're digressing and since our discussion is mostly about
> opinions I'd prefer to discontinue it. 
Agree to disagreeing then.

> Except for one rather important point:
> 
> > > - in general, the built-in compose function can't be called with
> > > zero arguments. For that purpose I cobbled myself:
> ...
> > I'd argue that compose without procedures is quite meaningless, but
> > maybe I'm thinking too hard.
> 
> Food for thought:
> 
> in Emacs Lisp:
> *** Welcome to IELM ***  Type (describe-mode) or press C-h m for
> help.
> ELISP> (-compose)
> #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_131>
> 
> In Racket:
> Welcome to Racket v8.10 [cs].
> > (compose)
> #<procedure:values>
> 
> Clojure 1.11.1
> user=> (comp)
> #object[clojure.core$identity 0x610db97e
> "clojure.core$identity <at> 610db97e"]
Looks like a bunch of implementation-defined behaviour to me.  Note
that rnrs barely specifies the case for two arguments :)

Cheers

Message #37 received at 66562-done <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: 66562-done <at> debbugs.gnu.org
Cc: Rostislav Svoboda <rostislav.svoboda <at> gmail.com>
Subject: Re: [PATCH v3] gnu: emacs-haskell-snippets: Use correct directory
 for snippets.
Date: Mon, 23 Oct 2023 09:58:43 +0200

Am Sonntag, dem 15.10.2023 um 20:25 +0200 schrieb Liliana Marie
Prikler:
> This package instructs Yasnippet to look for snippets relative to its
> own
> path.  However, it installs the snippets directly to site-lisp, which
> as of
> 79cfe30f3eb10bd3dbf7aa0f6e873c945d7d0ea5 is one directory above
> that.  Use the
> elpa-directory procedure introduced in that commit to rectify this
> mistake.
> 
> * gnu/packages/emacs-xyz.scm (emacs-haskell-snippets)[#:phases]
> <install-snippets>: Use elpa-directory.
> 
> Fixes: 66562
> ---
Made the fixes line more descriptive and pushed.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.