unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Josselin Poiret via Bug reports for GNU Guix <bug-guix@gnu.org>
To: Andrew Tropin <andrew@trop.in>, 62287@debbugs.gnu.org
Subject: bug#62287: Ungexp inside vector problem
Date: Mon, 20 Mar 2023 11:45:11 +0100	[thread overview]
Message-ID: <875yavsnuw.fsf@jpoiret.xyz> (raw)
In-Reply-To: <87v8iw3rbg.fsf@trop.in>

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

Hi Andrew,

Andrew Tropin <andrew@trop.in> writes:

> I would expect two last expressions return the same result, but the
> former one doesn't do ungexp:
>
> --8<---------------cut here---------------start------------->8---
> (define a '(3 4))
>
> (define b `#(1 2 ,a))
>
> (eval-with-store
>  #~(list '(1 2 #$a))) ;; => ((1 2 (3 4)))
>
> (eval-with-store
>  #~(list #(1 2 #$a))) ;; => (#(1 2 (ungexp a)))
>
> (eval-with-store
>  #~(list #$b)) ;; => (#(1 2 4))
> --8<---------------cut here---------------end--------------->8---
>
> Am I doing/expecting something wrong or there is a bug here?

It's more related to how the guile reader works, and this is such a
corner case that I don't know whether we should fix.  Basically,
anything starting with # is a reader extension, and the next character
identifies which extension it is.  #( is the reader extension for
vectors, #~ for gexp and #$ for ungexp.

To simplify, whenever you use #~, guile will insert (gexp ...) instead,
which is a hygienic macro (not just a procedure!), that will look for
ungexps inside the expression.  That traversal is only made on cons
cells though, so it doesn't try to go through any piece of syntax that
is not a cons cell!  Since #( doesn't expand to a (vector ...)
cons-cell, the subexpression gets ignored for traversal.

This is in contrast to another reader extension, #' (for syntax), which
does expand to (syntax ...), and is thus further traversed!

You can find how both of these reader extensions operate in
<libguile/read.c>.

I guess the immediate fix is to use (vector ...) rather than #(...).  We
could also add code to the gexp traversal to also traverse vectors, but
I am not even sure if they go through the gexp->sexp dance unharmed, and
we also should in principle do that for everything that can get into a
gexp, not just vectors (eg. bytevectors).

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

  reply	other threads:[~2023-03-20 10:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20  5:49 bug#62287: Ungexp inside vector problem Andrew Tropin
2023-03-20 10:45 ` Josselin Poiret via Bug reports for GNU Guix [this message]
2023-06-15  2:57   ` Andrew Tropin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875yavsnuw.fsf@jpoiret.xyz \
    --to=bug-guix@gnu.org \
    --cc=62287@debbugs.gnu.org \
    --cc=andrew@trop.in \
    --cc=dev@jpoiret.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).