Console Treatment of VOID vs. NOTHING

Domains Console
1

Rebol2 and Red both have a console property that when the console sees an UNSET!, it prints nothing:

>> block: reduce [<a> #[unset!] <b>]
== [<a> unset <b>]  ; bad rendering, conflates #[unset!] with the word `unset`

>> first block
== <a>

>> second block

>> third block
== <b>

This doesn't provide the best grounding in the console, especially considering that in their world an UNSET! is a reified value that can be found in a block.

However, returning an UNSET! is how functions like PRINT avoid outputting anything with == in the console:

rebol2>> print "Notice no == result"
Notice no == result

rebol2>> type? print "Test"
Test
== unset!

But What Result Should Ren-C Suppress?

Ren-C has two antiforms which might be considered candidates for not displaying... VOID and NOTHING.

Because voids vanish, it might seem to make the most sense to have voids not print anything, and trashes print out the standard isotopic form:

>> void

>> quote void
== ~void~

>> ~
== ~  ; anti

Looking at this, it might seem to make a lot of sense to have functions like PRINT and HELP return VOID.

BUT as I explain in "Why doesn't PRINT return VOID or NIHIL", there is a bit of a pitfall. Voids are friendly in terms of opting out of things:

>> append [a b c] print "If PRINT returned void..."
If PRINT returned void...
== [a b c]

This seems too friendly to me. There's another possibility of returning NIHIL, which would prohibit use as an argument. It would wind up making an evaluation appear to be void if no other expressions were in play...but if other expressions were involved it would let them fall out

>> print "If PRINT returned nihil"
If PRINT returned nihil

>> append [a b c] "If PRINT returned nihil"
If PRINT returned nihil
** Error: APPEND is missing its VALUE argument

>> 1 + 2 print "If PRINT returned nihil"
If PRINT returned nihil
== 3

So returning NOTHING feels like it makes the most mechanical sense...it has the right amount of ornery-ness:

>> print "Mechanically this works best"
Mechanically this works best
== ~  ; anti

But it's ugly to have that == ~ ; anti after every HELP or PRINT or other function.

Historically I've gone with NOTHING being invisible, and VOID printing a result.

>> ~

>> void
== ~void~  ; anti

But I've given a try at printing the results always to see what my feelings are.

1 Like
2

I gave a demonstration of Rebol to the KYOSS Group yesterday, and had to sort of wince at that basic first-impression situation:

>> print "Hello"
Hello
== ~  ; anti

It opens a can of worms right off the bat, by throwing the "anti" at people.

Though outputting nothing at all when you print is far from a universal expectation. Firefox and Chrome's JavaScript's consoles are explicit about returning undefined from functions like console.log:

 > console.log("hello")
   hello                       [VM146:1]
<- undefined

Clojure prints out nil:

=> (print "Hello World")
 Hello World
 nil

So utter silence doesn't seem like it's an expectation when you type PRINT. It's just that something about the ; anti part that makes it unsettling to a first-time user. A simple ~ might seem okay by comparison:

>> print "Hello"
Hello
== ~

But that's just incorrect. We have to distinguish ordinary quasi-blank from an antiform blank somehow.

Perhaps instead of ; anti it could say ; nothing

>> first [~]
== ~

>> do [~]
== ~  ; nothing

>> print "Hello"
Hello
== ~  ; nothing

That isn't much better, and probably does more harm than good in people's "isotopic education".

This only works if voids are picked as what the console does not display.

I can't avoid the fact that vaporization of PRINT makes me uneasy. I prefer making you write elide print.

There are downsides to it, but there are also upsides. It means PRINT would go back to being unusable in assignments:

>> x: print "Hi"
** Script Error: No value in isotopic BLOCK! pack: ~[]~ (nihil)

But you'd be able to tack it on the tail of expressions:

>> x: (1 + 2 print "Hi")
Hi
== 3

Maybe more people consider that a feature than bug... @rgchris and @gchiu have repeatedly asked why can't PRINT vaporize instead of having to write elide print. I've been stubborn about resisting, but mostly because I don't want people to become too casual about making vaporizing functions...the fewer, the better.

It's an immovable-object-meets-unstoppable-force situation...where I don't want to compromise the accuracy of the console, and I also don't want first impressions of the console to slap people in the face with confusion.

3

This behavior has flipped around more times than I can count, but I think when all is taken into consideration the right thing to do is to not display NOTHING.

It's a curious case of going full-circle, to align with historical Rebol's choice that what doesn't show is the same thing as what's in an unset variable. (Though there really are only so many choices.)

This does mean you don't see a "fully instructive feedback" on when something generates nothing. ...BUT, some cases like unset variables will often error before you even see that:

>> foo: ~

>> foo
** Error: ...

So that's at least some argument further in favor of it.

Further, now that voids are word antforms, they are no longer the "lightest" candidates representationally for vanishing, even if their meaning is vanishing-oriented.

>> if false [<a>]
== ~void~  ; anti

Remember, There Are Other UI Options in Rich Consoles

I think that if a light gray == ~ ; anti showed up and then faded out of the display, that might make a neat default. I'd have to see the effect.

1 Like