How many internal functions does the ren::Runtime need to expose?

[hostilefork]

Because C++ is not Red or Rebol, there is a difference when you write something like:

ren::Value someLogic = true;
std::cout << someLogic.isTrue() << "\n";

vs:

some-logic: true
print true? some-logic

The ability to bend and redefine words means there's an essential difference in the knowledge available to the guts of the system. Red runtime can know if a value is true or not without having to ask through a word, and the current way the C++ binding is implemented... it too has this ability. If you wanted the binding to actually invoke true? you'd have to ask:

ren::Value someLogic = true;
std::cout << ren::Word{"true?"}(someLogic) << "\n";

So this asks a question of how many hooks the binding should have into the system, and when (if ever) the behind-the-scenes implementation of anything that doesn't appear to invoke the evaluator should invoke it directly.

A good example is illustrated above, where we see std::cout being willing to accept the red::Value result of applying the word. (Effectively an APPLY of the function retrieved from TRUE?) How is the string being FORMed to be output? Is it done by calling FORM, or is there a special API hook for it? Do bindings attempt to duplicate the work of FORM? (<--- No!)

In my opinion, if C++ iostreams are going to be willing to serialize red values it raises questions of what it is they want. But that's another question. The key here is whether any invisible dependencies on the environment should come from the binding. I'm leaning toward saying no.

But might it be good enough to get the system/lib versions? Are those trustworthy enough for the binding?