One concern over an infix TO is how it would collect its first argument, as it only completes one expression. So:
first back tail something to integer!
...is processed as...
first back ((tail something) to integer!)
(unless TO is left-#tight like the math ops are, then it would be first back tail (something to integer!) but I'm not suggesting it be tight)
This might displease people who don't like parentheses or find it counterintuitive, as they could have previously written:
to integer! first back tail something
@rgchris observed in chat that we might not fret so much about the potential for being forced to parenthesize the left of a TO by the TO-XXX specializations, which although asymmetrical could remain prefix (vs. postfix).
to-integer first back tail something
(first back tail something) to integer!
That's a thought. I don't know if people would expect postfix for consistency, e.g. (first back tail something) to-integer.
My other thought was just to have a good prefix fallback for TO. I can't think of a great one off hand, but a serviceable one could be CONVERT. It's a bit wordy and might be wanted for something else.
But an actual good alternate prefix form came up via @johnk was regarding the similarity of AS to CAST, and whether CAST could be the prefix.
first back tail something as block!
;-- ...means `first back (cast block! tail something)`
cast block! first back tail something
;-- ...means `cast block! (first back tail something)`
I know these ideas are a little "weird-seeming" but I do want to keep pushing on them. While we saw Rebol variants like Boron try to kill off infix entirely, I think that undermined one of the very reasons for Rebol's existence....which is to open up homoiconicity and an "evaluator-based" language to people who don't want their programs to come out looking like kernel lisp:
($define! $and?
($vau x e
($cond ((null? x) #t)
((null? (cdr x)) (eval (car x) e))
((eval (car x) e) (apply (wrap $and?) (cdr x) e))
(#t #f))))
A certain type of person sees that and wants to run screaming. And despite being able to understand it perfectly well, I feel like having a language of equal power where I can write if x = y + 2 [...] feels better, even if I have to learn the ropes a bit to realize why I can't write if y + 2 = x [...] and expect that to work.
So if we find the dial of naturalness wasn't tuned exactly optimally in historical Rebol, I think we should challenge it, because that's what Ren-C has always been about. And I don't want us to lose the ability to "re-skin" the system so it can run a module with Rebol2 semantics (or where I imagine most future Rebol users to come from, a Red skin).