Wrong behavior of datum labels.

[jcubic]

I've added a comment on Gitter and decided that this is in fact bug:

R7RS spec say:

The lexical syntax #n# serves as a reference to some object labelled by #n= the result is the same object as the

n= (see section 6.1).

But this is now how Gambit handle datum labels.

Test cases:

(define x (list
           '#0=(1 2 3)
           '#0#))
(print x)
(print (eq? (car x) (cadr x)))

(print "------")
(define x (list
           #0='(1 2 3)
           #0#))

(print x)
(print (eq? (car x) (cadr x)))

(print "------")
(define x '(#0=(1 2 3) #0#))

(print x)
(print (eq? (car x) (cadr x)))

They all should return #t no matter where the datum labels were used. This is how it works in Gauche and Kawa Scheme. I don't see the reason why the parser works differently when there is quote in the front of expression. From what I see the parser should ignore that quote and just map '(...) to (quote (...)) without changing the logic of the parser inside the the expression.

[dpk]

For the record, with Gambit 4.9.5 the example prints #f, #f, and #t.

Your second example is not valid R7RS small code because the datum label appears outside of the literal itself and is therefore in code, not a literal — even though it refers to a literal. Just after the bit you quoted on page 9:

It is an error for a ⟨program⟩ or ⟨library⟩ to include circular references except in literals.

An implementation is free to do what it wants in this case.

Your first example is not exactly clearly defined by the spec, but I think returning #f here is allowed too. It’s not defined by the spec what happens when one literal includes a datum label defined within a different literal. @johnwcowan may have something useful to say about this.

[johnwcowan]

Not much, except that Chibi returns #t #t #t. I'm still struggling to get Docker set up properly on Windows 11.