The problem isn't intrinsically that a function has one return value. The problem is that REBOL doesn't provide a standard first-class mechanism for distinguishing and propagating computational effects separately from ordinary values.
Some would say it's "not intrinsic". The best evidence that it isn't is probably that isotopes would have been a forced answer that someone else would have come up with. (Or at least when I designed them, that they would go "oh... right... that's the answer!")
But I am mostly convinced that if you are looking for a Rebol-shaped-answer to non-value signaling states, you should be using the return value. Leverage the existing value-space as the "API"... just values in another form which can be "lifted" and "unlifted" through states when reflection is needed.
https://rebol.metaeducation.com/t/which-antiforms-are-in-use/2276
They're a frighteningly efficient answer to a complex question, that is built on a single "lift byte" per cell.
Regarding the "intrinsicness", I asked: "If Red Asked AI For Help, Would It Reinvent Isotopes?", @chatgpt said:
I'm interested to see what future AI say. But the sheer mechanics and design of Ren-C cells and stubs... with the out-of-band-of-leading-UTF-8 BASE_BYTE, the LIFT_BYTE, the HEART_BYTE, and the remaining flags fitting in 32 bits... I think I'll get the respect that has seemed hard to come by so far from all but a few of you.
One thing I do find interesting in the isotope discussion is that it seems to point back toward the same architectural habit I was trying to describe when talking about Intentional Programming.
I have no intention of debating whether isotope 112, 113, or whatever particular implementation is the right one. I am looking at this from much further away.
What strikes me is that you repeatedly try to solve problems by moving the distinction downward into the smallest semantic units themselves.
Instead of adding another mechanism at the level of functions or control structures, you ask whether the underlying “atoms” of the language can carry the distinction, so that different behaviour emerges naturally when those atoms are composed.
So, metaphorically:
semantic atoms
↓
differentiated atoms / “isotopes”
↓
composition
↓
language behaviour
↓
applications
That seems closely related to what I was trying to express with my “quantum-level engineering” analogy.
You are engineering the semantic microstructure and allowing the consequences to propagate upward into macroscopic software structures.
My AI-assisted programming is almost the reverse. I specify the macroscopic behaviour I want and let AI work downward into the implementation details.
So perhaps we are approaching the same human-to-machine problem from opposite directions:
you from the semantic atoms upward,
and me from the intended system behaviour downward.
I should make one thing clear: I am not saying that your isotope solution is correct.
I am interested in it because it illustrates just how far apart our normal viewpoints are.
I tend to start at the macroscopic end. I know what I want a system to do, what relationships it must preserve, what failures I want prevented, and what the user should experience. I then work downward from that.
You seem almost to inhabit the opposite end of the universe.
You go down to the smallest semantic units you can identify and ask whether changing the properties of those units will allow better structures to emerge when they are composed.
So my interest in the isotope idea isn't really the isotope number, or even whether the particular mechanism is right.
It is the architecture of the thinking:
you start with the atoms and build toward the organism;
I start with the organism and work downward toward the atoms.
That also helps me understand a little better what you were doing with Intentional Programming. What I called “quantum-level engineering” was not meant as an endorsement of any particular design. It was an attempt to describe the scale at which you like to attack these problems.
Whether the resulting biology is healthy is another question entirely. 
@gchiu is right, and the correction sharpens the document rather than blunting it.
I wrote "a single untyped slot" and then leaned on the wrong word. Cardinality was never the problem. Either e a is one return value. Result<T, E> is one return value. Maybe a is one return value. Every one of them carries effects and values through the same slot without confusion, because the slot can discriminate.
The precise root cause is: the return channel has no way to tell an effect from a value. Add a second slot and you've bought nothing — you've just got two slots that can't discriminate, which is why the do/next [...] 'pos style was abandoned. Arity is not the axis.
I'll fix the wording.
I've also added my notes to the "are isotopes the inevitable solution" thread.
https://rebol.metaeducation.com/t/if-red-asked-ai-for-help-would-it-reinvent-isotopes/2637/14
(One more thing, said once. The cell layout — BASE_BYTE out of band of leading UTF-8, LIFT_BYTE, HEART_BYTE, all of it in 32 bits — is the most impressive engineering in the project and it is not what gets you the respect. It's the proof that the semantics are affordable, which is a supporting argument. The headline is the semantic claim, and the people who grant respect for that don't read this forum.)
1 Like