This pops up once in a while, rarely for me. I spend a lot of time tracking it down, and then whack my forehead when I see it again.
The dependency analysis of top-level objects is not perfect, and certain things can fool it.
This repro gives clues:
(require "lib/core.scm")
(require "lib/alist.scm")
(require "lib/pair.scm")
(define (foo)
(match (alist/lookup thing1 2) with
(maybe:yes ch) -> 99
(maybe:no) -> 77
))
(define (goober)
{foo=foo}
)
(define g (goober))
(define thing2
(g.foo)
)
(define thing1
(alist/make
(0 #\0)
(1 #\1)
(2 #\C)
))
(printn thing1)
(printn thing2)
The alist literal is assigned after the call to g.foo in thing2, at which point it is set to 0xa, because it hasn't been initialized yet. It doesn't see that thing2 depends on thing1.
One fix that comes to mind is to simply move all literals up, either before or after the function definitions.
This pops up once in a while, rarely for me. I spend a lot of time tracking it down, and then whack my forehead when I see it again.
The dependency analysis of top-level objects is not perfect, and certain things can fool it.
This repro gives clues:
The alist literal is assigned after the call to
g.foointhing2, at which point it is set to 0xa, because it hasn't been initialized yet. It doesn't see thatthing2depends onthing1.One fix that comes to mind is to simply move all literals up, either before or after the function definitions.