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