Historically it is not possible to dispatch infix functions from a path. In Ren-C it's very nearly technically possible, with one problem: so long as PATH! can contain a GROUP!, it can't be "sniffed" for whether it looks up to an infix function without potentially having side effects.
Consider, for example:
do/next [1 foo/(print "Hi" 'bar) 2]
Let's say we want to think that if foo/bar looks up to something like infix addition, that should print "Hi" and be 3. If it is some prefix arity one function, it should print nothing and return 1.
The evaluator isn't designed to be able to predict the future in this way; you can't find out what foo/(print "Hi" 'bar) will look up to without evaluating the GROUP!. You don't want pure lookahead to have side effects. And really this is the technical dilemma in having paths dispatch infixed functions.
One possibility I've suggested is to disallow GROUP! under DO in paths unless you use a GET-PATH! or SET-PATH!. Since a GET-PATH! cannot dispatch a function, the problem goes away. If you needed function dispatch you could still get it with EVAL:
do/next [1 eval :foo/(print "Hi" 'bar) 2]
But since there's only one FUNCTION! type and its only variables that hold infixedness, that would not be infix.
Note: We could have an
envaloperation (possibly bad name), which is an infixed variadic, and would gather its left hand argument and then use its first right hand argument to determine how to interpret its parameters...effectively letting you signal an infix execution. e.g.1 enval :add 2=> 3
So how bad would it be if you could not--in the DO dialect--use a GROUP! in a path unless it was a GET-PATH! or SET-PATH!? Is it worth it to allow a regular PATH! to honor the infix bit of its target?