Or use prefab structs, which are non-generative and so cross phases and namespaces freely. They have corresponding limitations, of course, but whether that matters depends on your situation.

@mflatt Is it currently possible to configure the linklet flattener in such a way that it treats an arbitrary set of bindings as “primitive”, instead of what host Racket considers primitive? For example, if I wanted to use the flattener to compile some Racket code to JS, and I wrote a Racket module that implemented some JS primitive operations in Racket, could I use the flattener in a mode where it would leave references to phase 0 bindings in that module alone so that I could write a linklet-to-JS compiler that handled those operations specially?

@lexi.lambda one relatively straightforward way to do that is to access all those bindings via a primitive-table and then use ++knot js-primitive - to treat them as primitive

where js-primitive is the name of the primitive table you create

see uses of ++knot in the expander/Makefile for some inspiration

@samth what’s a primitive-table?

@samth Thanks, that makes sense… I’d been looking at some of the primitive table stuff, but I didn’t totally understand how it worked. I think what you said is enough to point me in the right direction, though. It would be nice if I could also make referring to %#kernel bindings an error, but I didn’t see an easy way to do that. I guess I could ++disallow all of them, though I’m not sure if that would work.

@notjack it’s part of the low level bootstrapping process

Basically just a named hash table

@samth Looking at things again, it looks like ++knot only works for #% modules that are “wired in”. But I guess I could write my own wrapper around extract that calls declare-hash-based-module! directly, given my custom primitive table?

I’m not sure if that’s really quite right, though… I only really want to redirect phase 0 uses in the expanded program, since any phase 1 uses ought to use the Racket implementation. And it would be nice if programs could still import my module using its usual module path instead of having to indirect through some magical #%js-primitive module.

~Though I suppose hash-based modules don’t have to be cross-phase persistent, so maybe the phasing issue isn’t actually a problem.~ Scratch that, I think they do have to be cross-phase persistent (which makes sense, since they’re just hash tables full of values). But I think it might be possible to adjust extract so it can do that knot-tying without needing to be a #% module.