bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#68413: Ungexp doesn't work on deep lists


From: Ludovic Courtès
Subject: bug#68413: Ungexp doesn't work on deep lists
Date: Mon, 15 Jan 2024 10:46:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Hi,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> Justin Veilleux <terramorpha@cock.li> writes:
>
>>> (define packages
>>>         (list
>>>          (cons "coreutils" coreutils)
>>>          (cons "make" gnu-make)
>>>          ...))
>>>
>>> #~(for-each
>>>    (lambda (f)
>>>      ... do-something)
>>>    '#$packages)
>>
>> If I send a patch to "fix" this, will it be usefull or is there a reason
>> for this behavior?
>
> I think IMO that it's a bug, but it's also quite tricky to properly
> traverse deep structures like this.  The bug comes from the fact that in
> gexp->sexp, we traverse lists by matching the reference with (refs ...),
> but that doesn't match if the reference is a pair instead.  Then, it
> tries to match with ($ <gexp-input> (? self-quoting? x)), which does
> match since self-quoting? apparently returns #t on a pair, whether or
> not its constituents are also self-quoting.

Actually, what bug are we talking about?  It seems to work for me with
this example:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (define packages `(("coreutils" ,coreutils) ("make" 
,gnu-make)))
scheme@(guile-user)> ,build (scheme-file "foo" #~(begin '#$packages))
building /gnu/store/lq9gvbilv0y2nph00zxk6bn3lvcgdxqq-foo.drv...
$7 = "/gnu/store/9ryh6v80jvjv3kwx0q782h26h9gbaclj-foo"
scheme@(guile-user)> (call-with-input-file $7 get-string-all)
$8 = "(begin (quote ((\"coreutils\" 
\"/gnu/store/mppp9hwxizx9g9pikwcvvshb2ffxyq7p-coreutils-9.1\") (\"make\" 
\"/gnu/store/9fadhs5qmwl5x7f669a0v39b3ryrmmf1-make-4.3\"))))"
--8<---------------cut here---------------end--------------->8---

One of the design decisions for gexps was to ensure that substituting a
file-like object by its file name would be O(1) in most cases.

Substitution in lists as in the example above is supported, but
primarily for backward compatibility.  It should be avoided when
possible because it’s inefficient: ‘gexp->sexp’ needs to traverse the
whole list/tree in search of potential candidates.

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]