Killing PRIN,PRINT/ONLY => WRITE-STDOUT (SPACED,UNSPACED)

In the quest to rid the Rebol world of ugly things, one thing I never liked was PRIN.

Besides looking bad, dropping the last letters off of things to get a more primitive behavior was not used anywhere else. After all, APPEND/ONLY wasn't called APPEN.

So an early concept I advocated for was that PRINT/ONLY made more sense. /ONLY was Rebol's convention for saying "just do the basic thing you do, by which I could implement any behavior...don't throw in the extra behavior that happens to be desired 80% of the time". That would apply here: if PRINT didn't throw a newline on the end, you could still generate any output you wanted...you'd just be saying print ["some text" newline] a lot. :-/

As with most simple-seeming decisions of this nature, it wasn't so simple. There was an added twist in this, in that there were two features that PRINT seemed to "throw in" that people may or may not want. Newline was one of them. The other was auto-spacing elements in the block. So would this /ONLY mean no newline, no spacing, or both?

Long debates and experiments on PRINT asked questions like "what if it didn't space by default, and you had to use BLANK!" (like print ["eg" "gplant" _ "ba" "nana"]). Or "what if it spaced by default, but using nested blocks could group things into tight formations". e.g. print [["eg" "gplant"] ["ba" "nana"]]. Trying various things all pointed back to the idea that in practice, "sensible" spacing (which didn't put spaces at ends of lines or around elements opted out via void or blank) was the most common intent...and every attempt to be any more "clever" than that just made it more confusing than being explicit in the code.

Rather than try to put a lot of complex logic into PRINT, it was built as a higher level usermode operation that called WRITE-STDOUT and made use of a function called SPACED. It was SPACED that would take the PRINT's block and turn it into a string for writing to standard output. A complementary function UNSPACED could be used by those who wanted unspaced output:

 >> print [{one} {two}]
 one two

 >> print spaced [{one} {two}] ;--winds up being equivalent
 one two

 >> print unspaced [{one} {two}]
 onetwo

This was literate, offered choices, and UNSPACED was the real intent behind most REJOINs. This had the benefit of allowing those who merely wanted to produce the strings as-PRINT-would-output-them the power to do so.

(Note: both SPACED and UNSPACED are specializations of a generic function called DELIMIT. It handles the logic of how to deal with "opted-out" elements that are blank or void, not putting delimiters around before or after newlines or single characters, etc. This logic is often gotten wrong and goes unnoticed, e.g. printing spaces before newlines that slip under the radar since you don't see them--that was a problem many people overlooked in R3-Alpha at certain points. So it's good to run it all through something that is vetted.)

It would seem that with this angle solved, there's no longer contention for /ONLY and it could just be made to not add a newline. but...not so fast.

PRINT is now implemented as a higher-level operation on top of a basic output routine (write-stdout currently, but you could imagine it being write stdout or write stdout://). It seems to me that instead of offering PRIN you could be expected to merely think of it as a direct write to stdout.

This means that if you have a BLOCK! and you want to output it unspaced without a newline, you'd say write-stdout unspaced [...] instead of print/only unspaced [...]. In the case of spaced output, you'd have to say write-stdout spaced [...] instead of just print/only [...]. It's a minor amount wordier but doesn't use a gibberish word, and offers you a level of control that you're probably going to need anyway if you're not using normal PRINT...I'd imagine most PRINs that took blocks were previously prin rejoin [...]. :-/

When you think about it, PRIN can be avoided most of the time. As a pattern, imagine someone trying to achieve spaced output but their calculations are broken up so all the information isn't available at once:

 prin "Some stuff " ;-- trailing space
 x: 10
 prin x
 prin space
 x: x + 1
 prin [x newline]

We have better tools--e.g. you could solve this with a COLLECT and it's more coherent:

 print collect [
     keep "Some stuff" // no terminal space needed
     x: 10
     keep x
     x: x + 1
     keep x
]

We're always challenged to figure out what to put in the box and what to leave people to define on their own. I'd like what's in the box to have Quality with a capital Q. People can easily invent a PRIN if they need it, but putting such a word in lends it an endorsement that I don't think it should be given. Writing to stdout directly when you need that level of control seems like a clearer model, and WRITE-STDOUT plus UNSPACED/SPACED/DELIMIT gets you there.

So I'm recommending that the current /ONLY refinement be removed from PRINT. Usages of it should be reviewed for the cases in which it truly can't be done with a PRINT COLLECT. (One legitimate such use is the console printing a prompt but leaving the cursor on the same line, although even when it comes to color codes and cursor positioning, it really should be using write console:// instead of write stdout:// to get those features).

I still do like PRIN. Here is why.
I use it a lot as debugging method, plugging in PRIN or PROBE statements showing the values I am working on and are possibly responsible for the unexpected behaviours I am facing.
PRIN is much shorter than WRITE-STDOUT UNSPACED (even without UNSPACED).
When used in the way you have in mind here, there is a good argument of using this as you propose, as it is cleaner and does not a not existing word, having said that dictionary.com does not know the word 'STDOUT' either.
As PRIN is probably used in many many scripts, I want to express my view here in that I think it is best to keep PRIN around for backward compatibility. Despite its 'uglyness'. As an alternative use of PRIN could certainly be discouraged, stating in documentation and help string it is only to be used for the debugging purposes like I mentioned before and let the help point to the 'correct' WRITE-STDOUT.

I certainly am not arguing for the idea that it be difficult to define PRIN in its legacy form, for those needing compatibility.

I'm just saying what I think is obvious, that it is not something that "belongs in the box" name-wise, and I think we should raise the bar of thought. Let's see code samples that use it, and, review them, and ask if we might make a better world without a PRIN.

If TYPE can be used, that would exactly do as it says. But probably that is too similar to type! ?

(Also the argument that other languages do not use something like PRIN is not relevant. Some choose things even worse like printf.)

What is wrong with ECHO ? Does that suggest a newline afterwards?
Another alternative could be found in the verb to rap, so RAP. Rapping words is just saying them quickly without spaces and newlines. RAP also has a French touch in the French word rappeler, to recall or remind.

You also reminded about the often forgotten DUMP.