>atomic.rkt:6:9: module: provided identifier not defined or imported for phase 0 at: current-atomic
>(provide atomically current-atomic
>(define current-atomic (internal-make-thread-parameter 0)) It is defined like this in chez. Why is this not for phase 0?
@mflatt we’re still confused
I sort of addressed the above problem by defining in the other version of racket’s future.rkt module a current-atomic. And now I am back to the original error of >/home/spall/iu/hash-tables/racket7/racket/collects/racket/future.rkt:21:10: provide: provided identifier is not defined or required at: current-atomic
I think I’m missing a lot of context, including what you’re changing overall and which step of the build fails; maybe it would be eaiser if you pushed to a branch somewhere
@mflatt I pushed the code to my racket7 fork on the branch futures-blocking
I think this should recreate my problems
I just saw this line in the expander.rktl "(define-values (datum->syntax$3) (hash-ref kernel-primitive-table$1 ’datum->syntax))", does this mean that the ’datum->syntax needs to be provided by the runtime for the datum->syntax (the one in the expander) to work?
or is this datum->syntax$3 another thing? (that seems to be used only in correlated stuff)
@cadr I believe that the kernel provides datum->syntax which produces a “correlated”
@mflatt just to say more about the goal, @spall is trying to provide current-atomic, start-atomic, end-atomic from the cs layer to the “thread” layer
@spall @samth Ok, I didn’t understand that you’re trying to import into the “thread” layer. To make it possible to run and test that layer by itself (via make demo in “thread”), the “thread” layer receives core functionality through an '#%engine table; see “thread/engine.rkt” for where that functionality is bound for use by the “thread” layer, “thread/bootstrap.rkt” where drivers are provided for make demo mode, and “cs/thread.sls” for where '#%engine is set up to provide “core.sls” implementations to the “thread” layer in Racket-on-Chez. I think you don’t want to modify “racket/collects/racket/future.rkt” at all, assuming that you’re not trying to export functionality outside of the “thread” layer.
But you can’t export a Chez macro like atomically to the Racket layer
More generally, I worry that moving atomic-mode tracking from the “thread” layer to the “core” layer is moving in the wrong direction. Is there a more minimal core support for futures that would let you implement futures mostly at the “thread” layer, instead?