Console Treatment of VOID vs. TRASH

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 multiple antiforms which might be considered candidates for not displaying, with differing claims on the title of "nothingness"

  • VOID! (antiform COMMA!)
  • HEAVY VOID empty PACK! (antiform GROUP!)
  • TRASH (antiform RUNE!)

The voids kind of go together as a set.

It might seem to make the most sense to have the VOIDs not print anything...since there is no value to be gotten out of them. Then trashes print out the standard isotopic form.

Such a world would look like this:

>> ~

>> ~()~

>> lift ~()~
== ~()~

>> ~#[some trash]#~
== \~#[some trash]#~\  ; antiform (void!)

If you buy into that, it might seem to make a lot of sense to have functions like PRINT and HELP return HEAVY VOID.

BUT as I explain in "Why doesn't PRINT return VOID", there is a bit of a pitfall. VOIDs (heavy or otherwise) 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 VOID and being vanishable...

>> print "If print was returned void"
If print returned void

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

>> 1 + 2 print "If print returned void"
If print returned void
== 3

So returning TRASH 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
== \~#[print]#~\  ; antiform (trash!)

But it's ugly to display the TRASH! after every HELP or PRINT or other function.

Historically I've gone with TRASH being invisible, and VOIDs printing a result.

>> ~#[trash]#~

>> ()
== \~\  ; antiform (void!)

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

1 Like
Making CALL Raise a (definitional) Error For Bad Exit Codes
What Are NULL, VOID, NONE, and TRASH ?
Why Doesn't PRINT Return Empty Pack ("heavy void")?
Why Are TRASH and VOID Distinct In Ren-C?
Presentation to KYOSS, September 2023
How Console Displays Things With No Literal Representation
2

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

>> print "Hello"
Hello
== \~\  ; antiform

It opens a can of worms right off the bat, by throwing the "antiform" 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 ; antiform part that makes it unsettling to a first-time user. A simple ~\ might seem okay by comparison:

>> print "Hello"
Hello
== \~\

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.

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 TRASH.

Remember, There Are Other UI Options in Rich Consoles

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

1 Like