Inconsistency with expressions between definitions

Inconsistency with expressions between definitions

[Dr. Arne Babenhauserheide]

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

Hi,

while writing a comment to SRFI-245 I think I found an inconsistency in
the Implementation in Guile.

This works:

(define (using-later-variable)
  (define x y)
  (define y #t)
  x)
(using-later-variable)
;; => #t

This still works:

(define (using-later-variable)
  (define x y)
  (newline)
  (define y #t)
  x)
(using-later-variable)
;; => (newline output)
;; => #t

This fails:

(define (using-later-variable)
  (define x y)
  (display x)
  (newline)
  (define y #t)
  x)
(using-later-variable)
;; => #<unspecified>

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

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

Re: Inconsistency with expressions between definitions

[Linus Björnstam]

Hey!

When you are not referencing x before defining y everything works as you 
want. There is no, so to say, temporal dependency on how the things are 
bound. When you introduce (display x) before actually defining y you 
force letrec* to bind x to the unspecified value, because display has 
side-effects and you don't move around side-effecting code.

If you do (display "heippa!") instead it works as you want.

I believe racket (which does the same optimization) has the same behaviour.

-- Linus Björnstam

Den 2023-09-24 kl. 09:09, skrev Dr. Arne Babenhauserheide:
> Hi,
> 
> while writing a comment to SRFI-245 I think I found an inconsistency in
> the Implementation in Guile.
> 
> This works:
> 
> (define (using-later-variable)
>    (define x y)
>    (define y #t)
>    x)
> (using-later-variable)
> ;; => #t
> 
> This still works:
> 
> (define (using-later-variable)
>    (define x y)
>    (newline)
>    (define y #t)
>    x)
> (using-later-variable)
> ;; => (newline output)
> ;; => #t
> 
> This fails:
> 
> (define (using-later-variable)
>    (define x y)
>    (display x)
>    (newline)
>    (define y #t)
>    x)
> (using-later-variable)
> ;; => #<unspecified>
> 
> Best wishes,
> Arne

Re: Inconsistency with expressions between definitions

[Dr. Arne Babenhauserheide]

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

Hi,

Linus Björnstam <linus.bjornstam@fastmail.se> writes:

> When you are not referencing x before defining y everything works as
> you want. There is no, so to say, temporal dependency on how the
> things are bound. When you introduce (display x) before actually
> defining y you force letrec* to bind x to the unspecified value,
> because display has side-effects and you don't move around
> side-effecting code.

This is a technical explanation. It answers "how does this happen?"
(thank you for that!), but not "why is this the correct behavior?".

The core problem I see: if you inject some logging code between the
defines, the behavior changes.

I would expect that referencing a variable that can’t yet be used in an
intermediate expression (between defines) would not cause a (potentially
subtle) behavior change, but would throw an error: variable used in
expression that depends on later define.

Racket does not support defines using later defines at all:

$ racket
> (define (using-later-variable)
>      (define x y)
>      (define y #t)
>      x)
> (using-later-variable)
y: undefined;
 cannot use before initialization
 [,bt for context]

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

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

Re: Inconsistency with expressions between definitions

[Linus Björnstam]

Hi again!

I am not sure about letrec*, but this should really raise an error in r6rs. You cannot reference a variable before it is assigned. 

I said it "would work in racket" because I believe it uses the same algorithm for deciding when and how and where and how and when things are bound in letrec*. This should also be the case in chez, but chez displays an error. Given I have found the chez is never wrong with regards to R6RS we can say that guiles behaviour is not conformant with r6rs. 

It is also inconsistent with regards to guiles manual, at least if the part on internal definitions is to be believed. 

What I am saying is: congrats, you found a bug :)

Sorry about confusing you. I was never really sure about letrec* behaviour, but you nerdsniped me and I spent some time reading the "fixing letrec (reloaded)" paper, and now things are more clear.

-- 
  Linus Björnstam

On Sun, 24 Sep 2023, at 18:02, Dr. Arne Babenhauserheide wrote:
> Hi,
>
> Linus Björnstam <linus.bjornstam@fastmail.se> writes:
>
>> When you are not referencing x before defining y everything works as
>> you want. There is no, so to say, temporal dependency on how the
>> things are bound. When you introduce (display x) before actually
>> defining y you force letrec* to bind x to the unspecified value,
>> because display has side-effects and you don't move around
>> side-effecting code.
>
> This is a technical explanation. It answers "how does this happen?"
> (thank you for that!), but not "why is this the correct behavior?".
>
> The core problem I see: if you inject some logging code between the
> defines, the behavior changes.
>
> I would expect that referencing a variable that can’t yet be used in an
> intermediate expression (between defines) would not cause a (potentially
> subtle) behavior change, but would throw an error: variable used in
> expression that depends on later define.
>
> Racket does not support defines using later defines at all:
>
> $ racket
>> (define (using-later-variable)
>>      (define x y)
>>      (define y #t)
>>      x)
>> (using-later-variable)
> y: undefined;
>  cannot use before initialization
>  [,bt for context]
>
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>
> Attachments:
> * signature.asc

Re: Inconsistency with expressions between definitions

[Dr. Arne Babenhauserheide]

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


Linus Björnstam <linus.bjornstam@fastmail.se> writes:

> are bound in letrec*. This should also be the case in chez, but chez
> displays an error. Given I have found the chez is never wrong with
> regards to R6RS we can say that guiles behaviour is not conformant
> with r6rs.
…
> What I am saying is: congrats, you found a bug :)

☺

> Sorry about confusing you. I was never really sure about letrec*
> behaviour, but you nerdsniped me and I spent some time reading the
> "fixing letrec (reloaded)" paper, and now things are more clear.

I guess "sorry"? Or rather "you’re welcome"? :-)

I guess the next step would be to report a bug …

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

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