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