Inconsistency with expressions between definitions

2023-09-24 Thread 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)

Re: Inconsistency with expressions between definitions

2023-09-24 Thread 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

Re: Inconsistency with expressions between definitions

2023-09-24 Thread Dr. Arne Babenhauserheide
Hi, Linus Björnstam 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 val

Re: Replacing Guile test-suite with SRFI-64?

2023-09-24 Thread Maxime Devos
Op 23-09-2023 om 17:13 schreef Mike Gran: Hi, Would a rewrite of the Guile tests using SRFI-64 be a welcome idea? IMO the advantages of doing so are: ... Opinions? IMHO, I think Guile should not depend too heavily on Guile for testing itself. It is bad bootstrapping practice. Whether

Re: Replacing Guile test-suite with SRFI-64?

2023-09-24 Thread Mike Gran
> A benefit of SRFI-64 is that the SRFI-64 implementation has tests > whereas (IIRC) Guile's custom thing doesn't. OK two separate issues. 1. Mike G's gripes about SRFI-64. 2. Updating over 65,000 lines of test code I don't want to be put in the position of having to make a critique of SRFI-64,