Ungexp inside vector problem

Open

Details

2 participants

Andrew Tropin
Josselin Poiret

Owner: unassigned

Submitted by: Andrew Tropin

Severity: normal

Andrew Tropin wrote on 20 Mar 2023 06:49

Recipients:(address . bug-guix@gnu.org)

Message-ID:87v8iw3rbg.fsf@trop.in

I would expect two last expressions return the same result, but the

former one doesn't do ungexp:

Toggle snippet (14 lines)

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

Am I doing/expecting something wrong or there is a bug here?

Best regards,

Andrew Tropin

Josselin Poiret wrote on 20 Mar 2023 11:45

Recipients:

Message-ID:875yavsnuw.fsf@jpoiret.xyz

Hi Andrew,

Andrew Tropin <andrew@trop.in> writes:

Toggle quote (20 lines)> 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

Andrew Tropin wrote on 15 Jun 2023 04:57

Recipients:

Message-ID:87edmdh1pz.fsf@trop.in

On 2023-03-20 11:45, Josselin Poiret wrote:

Toggle quote (50 lines)> 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).
>

Thank you very much for extensive explanation!  I have a few tasks
related to the guile reader extensions, so when I get my hands dirty
with it, I'll probably share my new thoughts and opinions on this topic.

-- 
Best regards,
Andrew Tropin

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 62287@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 62287

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date