Calling Ren Functions From Redbol

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.

3 Likes