When you import @redbol
the environment for your module is skinned with the Redbol definitions. But it can run concurrently with non-Redbol modules in the same session. This is very cool.
I've nudged it a little further into cool by having the definition of LIB in Redbol be the initial state of the Redbol definitions, and then REN is the Ren-C's version of LIB.
>> import @redbol
>> append [a b c] [d e]
== [a b c d e]
>> append/only [a b c] [d e]
== [a b c [d e]]
>> ren/append [a b c] [d e]
== [a b c [d e]]
>> ren/append [a b c] ren/spread [d e]
== [a b c d e]
>> append: does [print "Overwritten"]
== #[action! {append} []]
>> append
Overwritten
>> lib/append [a b c] [d e]
== [a b c d e]
Pretty slick.
But IMPORT is Ultimately Not The Right Mechanism
Because it's done using import, Redbol does not "clear out" the space of all the Ren-Cisms.
In fact, I didn't actually have to say ren/spread because the spread definition is still available:
>> ren/append [a b c] spread [d e]
== [a b c d e]
It's non-viable to ask Redbol to remove every Ren-C definition. Instead, there needs to be a way to get a Redbol-using module to start from a fully clean slate where it explicitly exports everything it wants to make available. This doesn't have to be that much work, it can just be a list of words in a block, with possible renamings:
redbol-inherit [even?, odd?, value?: unset? ...]
These Challenges Are Great For Vetting
I don't throw softballs. This is all truly attempting to live up to the hype of a language that you can bend and redefine at will, without constantly tripping over your own changes--and being able to build on top of existing functionality without being forced to rewrite it too.
Although things move slowly... the arrow of progress is in the right direction.